20180425 AWS Black Belt Online Seminar Amazon Relational Database Service (Amazon RDS)
フェイルオーバー発生させたら、15分固まった。 Amazon RDS MySQL 5.6.23+Tomcat+JavaServlet+Connector/Jでコネクションプールを利用した環境で、RDSのフェイルオーバー試験をするべくManagement Consoleから「Reboot with Failover」を発生させたら、フェイルオーバーは数分で完了して他の新規接続も受け付けられているのに、前から接続していた分が固まってしまいました。 フェイルオーバーが始まった直後に投げたリクエストのあと、うんともすんとも言わない。 JDBCのconnectTimeoutは3秒にしてあって、SecurityGroupの設定ミスなどでつながらない場合は5秒でタイムアウトすることは確認済みなのに、このケースではお返事が帰ってこない。。。 ぐぐっても、新規接続時のタイムアウト(connectTimeou
RDS for PostgreSQL にシステムアップデートがやってきましたね。 Upgrade now available for your Amazon RDS PostgreSQL database instances 今回のアップデートは必須なので猶予期間の間に必ず適用する必要があります。 Multi-AZ 構成にしていれば自動的にフェイルオーバーしますが、60 〜 120 秒のダウンタイムは避けれません。 プロダクション環境の RDS で同様のメンテナンスは何度か経験しましたが、オフタイム(主に休日)にメンテナンスを計画しその度にエンジニアが待機していました。当日はメンテナンスに切り替えて見守るだけなのですが、メンテナンス告知など諸々の調整や休日出勤でそれなりの保守コストがかかっています。お客様にも迷惑をかけるしエンジニアにも負担を強いていたのです。 この機会に、実装やアーキテク
[toc] 昨年にAWSで体験した、苦い思い出の一つに、Amazon RDSのメンテナンスによる意図しないアップグレードがありました。 EC2インスタンスのメンテナンス情報はメールで来ていたので、RDSなど他のプロダクトもメンテナンスがある場合はメールで通知されるものだと思っていました。しかし、実際はメール通知されることなく、(自分達にとっては)突然メンテナンスが実施されてしまったのです。メンテナンス中はRDSへの接続ができないのでその間はシステムがダウンすることになり、数分間でしたが、影響範囲はとても甚大でした。 Amazon Auroraに移行していたので、Auroraがそういう仕様なのかなと思い、サポートに問い合わせてみたところ、メール通知されるなくアップグレードのスケジュールが行われることがあるため、DescribePendingMaintenanceActions APIを使うこ
AWS Black Belt Online Seminar「AWSで実現するDisaster Recovery」の資料およびQA公開 こんにちは、ソリューションアーキテクトの小川です。 先日開催致しました、AWSソリューションカットのオンラインセミナー「AWSで実現するDisaster Recovery」の資料が公開されております。QAの回答と併せてご紹介させて頂きます。 Q1: AZだけでなくリージョンをまたがって設計されるケースも多いですか? A1: はい、セッション内でも申し上げました通り、お客様のBCP/DRポリシーに基づいて必要に応じて複数リージョンをお使い頂くケースもございます。下記ページにてそのような構成事例も公開されておりますので、是非ともご覧いただけますと幸いです。 バックアップ・災害対策での AWS 国内導入事例 Powered by AWS クラウド https://
クラウド・コンピューティング環境における Oracle ソフトウェアのライセンス 本資料は、以下のベンダーが提供するクラウド・コンピューティング環境に適用されます: Amazon Web Services – Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) クラウド・コンピューティング環境におけるOracleプログラムのライセンス許諾の際には、「バーチャ ル コア」 「物理コア」 ・ を と同等に換算してカウントする必要があります。 このカウント方法は、 Processor の価格単位を持つすべてのプログラムに適用されます。 製品名称にStandard Edition OneもしくはStandard Editionが付くプログラムが許諾される場合、EC2コ ンピュータのサイズに基づく価格設定が
概要 Datadog に追加された linear regression functions (線形回帰関数) を利用して、DB などのストレージがあと何ヶ月で枯渇するかを予測するという話。 背景 ストレージに対する監視として、使用率が X% を超えたらアラートを出す、というのがオーソドックスなもの。例えば Increments では AWS の推奨閾値である 85 % (出典は関連資料項目を参照) を超えたら Slack に通知が来るようにしている。 しかし、使用率が 85% に達した時、残り 15% をどれくらいの期間で消費するかは実はさまざまなケースがある。緩やかにストレージを消費し、残り 3 ヶ月で消費するケースもあれば、残り 1 週間で消費するケースもあるだろう。残り 1 週間で枯渇するケースの場合、対応が慌ただしくなってしまうかもしれない。 そこで、現在の使用量に対する閾値監視だ
こんにちは、虎塚です。 今回は、DatadogでRDSを監視するために拡張RDSインテグレーションを有効にする手順を紹介します。 DatadogでのRDS監視 RDSのパフォーマンスデータをDatadogで利用するには、次の3つの方法があります。 標準RDSインテグレーション 拡張RDSインテグレーション RDS+ネイティブDBインテグレーション 1つ目の標準RDSインテグレーションは、CloudWatchのRDSメトリックス値をDatadogで使います。このインテグレーションは、AWSインテグレーションを実行してRDSを選択することで有効にできます。 AWSインテグレーションの設定手順は、次の記事を参照ください。 Datadog のAWS監視にIAMロールを利用してみた | Developers.IO 2つ目の拡張RDSインテグレーションは、RDSの拡張モニタリングで取得できる値をDat
目的 日々、成長していく(= データ量が増えていく)RDS を見守るために、見える化したい! そのために Datadog にメトリクスを送ってグラフ化してみました! 想定する対象の方 以下のような方が読んでも分かるようなものを目指してます Datadog のアカウントは持ってるよ(持ってるだけだよ) Datadog のアカウントは持ってないけど雰囲気だけ知りたいよ ※ アカウント作成に関しては Developers.IO さんの記事が詳しいです → Amazon Linux を Datadog で監視してみた そもそも Datadog って? 非常に柔軟なモニタリングサービスで、Saas の形で提供されています。 グラフがとても綺麗にできます。 tagというものが有り、それを使うと多次元に解析できたりもします。 一言で言うと、ホントにすごい奴です! 情報源 Datadog 本家 Datad
RDS ReadReplicaを立てて、参照クエリを逃がすことを考える。 可用性や拡張性を考えてReadReplicaは複数台構成とした場合、RDSの仕様を考慮して設計しておく必要がある。ポイントは以下。 Read Replicaは個々にEndpoint (DNS名) を持つ。 複数Read Replicaに対してバランシングする仕組みは提供していない。 ELBは RDS (Read Replica含め) には使えない。ELBにぶら下げられるのはEC2のみ。 Read Replica各ノードの死活監視、障害時の切り離し/切り戻しを考慮する必要がある。 ということで、Read Replicaのバランシングを行うなら、自分で仕組みを用意する必要がある。 実現方法はいくつか選択肢があるが、今回はL7のバランサーとして定評のあるHAProxyを使ってみる。 Architecture with HA
sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000 prepare sysbench --test=oltp --db-driver=mysql --oltp-table-size=10000 --oltp-read-only=off run AWSの場合はEC2、GCPの場合はCompute Engineに 同一のリージョンの仮想マシンを作成し、↑のコマンドを実行します。 今回はMySQLの設定値は特に変更しませんでした。 管理画面から設定できる値も基本的にデフォルトのままで。 気になる結果は…… 比較結果 RDS MySQL OLTP test statistics: queries performed: read: 140000 write: 50000 other: 20000 total: 210000 t
Amazon Aurora releases updates regularly. Updates are applied to Aurora DB clusters during system maintenance windows. The timing when updates are applied depends on the region and maintenance window setting for the DB cluster, as well as the type of update. Amazon Aurora releases are made available to all AWS Regions over the course of multiple days. Some Regions might temporarily show an engine
こんにちは、SAの舟崎です。 先日開催されたAWS初心者向けWebinar「RDBのAWSへの移行方法(Oracleを例に)」の資料を公開しました。 RDBをAWSへ移行するときの考え方や、移行先のRDBはAmazon EC2インスタンス上、あるいはRDSインスタンス上、どちらで構築すべきか、またOracle DBの移行に利用可能なツール等を紹介いたしました。こちらの内容はStrategies for Migrating Oracle Database to AWSのホワイトペーパーにも詳細が掲載されておりますので、是非ご参照ください。 以下は今回のWebinarで頂いたご質問とその回答です。(可能な範囲で掲載させて頂いております) Q1.RDSの導入時のサイジング方法はawsで公開していますか?むしろ導入前のサイジング推奨していないですよね? A1. AWSのメリットは柔軟にリソースが調
This version has been archived. For the latest version of this document, visit: https://docs.aws.amazon.com/whitepapers/latest/ strategies-migrating-oracle-db-to-aws/strategies- migrating-oracle-db-to-aws.html Strategies for Migrating Oracle Databases to AWS First Published December 2014 Updated January 27, 2022 This version has been archived. For the latest version of this document, visit: https:
Amazon Aurora 東京ローンチイベント 10/Nov/2015 発表資料 - RDS for MySQL から Aurora への移行に関する共有 事前に読んでおくべき資料 - Amazon re:Invent (DAT405) Amazon Aurora Deep Dive http://www.slideshare.net/AmazonWebServices/dat405-amazon-aurora-deep-dive - AWS Black Belt Tech Webinar シリーズ 2015 - Amazon Aurora http://www.slideshare.net/AmazonWebServicesJapan/aws-black-belt-tech-2015-amazon-aurora - RDS for AuroraとRDS for MySQL5.6のPar
はじめに こんにちは、yokatsukiです。 案件でVPCピアリングを使って、AWSアカウントが異なるの2つのVPCを接続しました。VPCピアリングに関する情報は数ありますが、RDSとの接続のように、IPではなくエンドポイント名での接続に関しては意外に情報がありませんでした。そこで、VPCピアリング越しにRDS接続した際の挙動について確認してみました。 前置き:VPCピアリングとは VPCピアリング(VPC Peering、VPCピア接続)とは、一言で言うと、2つのVPC間のL3ネットワーク通信を提供し、外部ネットワークなしでVPC間の相互接続を実現する機能になります。アカウント間でローカル接続が可能になるので、インターネット経由の通信と比較して、通信の高速化が期待できます。ただし、送受信1GBあたり、$0.01がかかります(2015/6/17現在)のでご注意ください。 概要はこちらのエ
Direct connect経由なFusion-IOとRDSはどっちが速いのかを繋いで、ベンチマークしてみた。 背景 目的 検証環境について TCP-Cについて ベンチマーク結果 コネクション時の通信帯域 MySQLサーバーのパラメーターの差異に関して 資料:セッティングパラメーター sysbench-lua 0.5について ベンチマーク結果 背景 RDBMSにおけるOLTP処理において、Fusion-io社のioDrive2はゲームなどを中心に非常に高い性能を示しており、各RDBMSのストレージとして採用されています。この事から、ioDrive2に匹敵する性能をクラウド求にられていくことが予想されます。 目的 本検証はハイブリッドクラウド環境において、ioDrive2搭載サーバの実運用性を検証することを目的としています。 EquinixにioDrive2を搭載した物理サーバを設置し、A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く