お客様のクラウド導入事例 さまざまな規模のお客様が AWS を使用して、アジリティの向上、コストの削減、そしてイノベーションの推進をクラウドで実現した方法を紹介します。
![導入事例 (Case Studies) - Amazon Web Services](https://cdn-ak-scissors.b.st-hatena.com/image/square/c4f530e16dfb308a48108c71972db725de90d0d5/height=288;version=1;width=512/https%3A%2F%2Fa0.awsstatic.com%2Flibra-css%2Fimages%2Flogos%2Faws_logo_smile_1200x630.png)
お客様のクラウド導入事例 さまざまな規模のお客様が AWS を使用して、アジリティの向上、コストの削減、そしてイノベーションの推進をクラウドで実現した方法を紹介します。
前回に続いてまたAuroraです、Aurora。高い可用性なのはわかっていますが、じゃあ具体的にどのくらいやねん、となると良い情報がなかったので調べることにしました。 Auroraの公式情報は、一定以上の知識を前提とした内容になっていて、良いバランスで心地よい感じなのですが、まだ読んでて楽しいコンテンツが欠けている印象です。一般情報も、出ました、使ってみました、とかしか無くて寂しいので、ブルーオーシャンを泳いでいくとしましょう。 AuroraのEndpoint 公式読めばいい所なので軽く復習ですが、現在のAuroraのEndpointは3種類あります。 Cluster Endpoint … 常にWriterを指すFQDN。参照更新の両用 Reader Endpoint … ランダムでReaderを返すFQDN。参照用 (Instance) Endpoint … インスタンス毎に割り当てられ
Product { this.openCategory = category; const productMenu = document.querySelector('.product-menu'); window.DD_RUM.onReady(function() { if (productMenu.classList.contains('show')) { window.DD_RUM.addAction(`Product Category ${category} Hover`) } }) }, 160); }, clearCategory() { clearTimeout(this.timeoutID); } }" x-init=" const menu = document.querySelector('.product-menu'); var observer = new Muta
Auroraがそこそこ浸透してきたように感じなくもないですが、そのわりに情報がまだ少なめなのは、それだけ従来のMySQLと変わりなく扱え、性能も十分満足いくものだろう、という証なのでしょうか。 中の人も、パラメータチューニングは済んでいるので、基本的にはスケールアップで対応してください、と申しているように、かなり良い調整がされているようです。しかし、インフラエンジニアというかエセDBAたるもの、何がどう調整されているかを具体的に確認しなくては気がすまないため、整理してみたわけです。 デフォルトの設定 パラメータグループについて Auroraのパラメータは従来と異なり、ノード毎の設定である『DB Parameter Group』と、クラスタ内共通の『DB Cluster Parameter Group』の2つに設定が分かれます。 必要に応じてクラスタの方に、文字コードやレプリケーション周りな
Photo via Visual hunt Backlog の一部のスペースにて Amazon Aurora へと移行しました。ここでは、その経緯と実際に実施した作業を簡単にご紹介させていただきます。 移行の経緯 昨年末データベース障害が発生しユーザー様には多大なご迷惑をお掛けしてしまいました。 Backlog には Terraform をどう使っているかを紹介したブログ にあるように複数の運用環境があります。 その各々の環境の構築時期によって EC2 上で自前運用していた MySQL もあれば、RDS for MySQL もある、といった統一されていない状況でした。また EC2 上ではまだ MySQL 5.1 も稼働していました。 移行を検討するにあたり、優先したのは障害時の復旧が素早く出来ることと、少しでも運用の管理コストを下げることでした。Backlog のサーバは 100 台以上で
このセクションでは、Aurora DB クラスターを管理し維持する方法を示します。Aurora は、レプリケーショントポロジに接続されているデータベースサーバーのクラスターに関連します。そのため、Aurora を管理するには、複数のサーバーへの変更をデプロイし、すべての Aurora レプリカがマスターサーバーで維持されていることを確認する必要があります。Aurora では、データの増加に伴い、基本となるストレージを透過的にスケーリングしているため、Aurora の管理に必要なディスクストレージの管理は比較的わずかです。同様に、Aurora では、継続的バックアップが自動的に行われるため、Aurora クラスターでは、バックアップの実行に伴う過度な計画やダウンタイムは必要ありません。
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
Amazon Auroraというクラウド上のRDBMSサービスがある。2015年の7月末にGAロウンチしたばかりのサービスだが、世界各国のユーザに非常に好評のようだ。 https://aws.amazon.com/rds/aurora/ Auroraをどう見るか、でクラウドの受け入れ度合いや現状の把握に使えると個人的には感じている。個人としてはAuroraほど画期的なサービスはDBでは今までなかったし、RDBMSの歴史の新しい1歩として認識している。ただあまりのシームレスさ、移行容易性、利用の簡便さに凄さに逆に気づきにくい状況がおきている。結果としてマーケティング的なムーブメントにはなりにくい状況で、個人としてはむしろそれが望ましいとも思っている。静かに深く世の中を変えていく、そんなサービスだ。ちなみにグローバルではOracleやSQL Serverからの移行が後を絶たない。理由の多くは、
開発コストは掛かったでしょうから、さすがにMySQLと同価格、とは行かなかったようですが、概ね1.2倍強の価格で提供されています。詳しくは料金表を御覧ください。 ちなみに、インスタンスクラスの選択肢は、現状上記5種類のようです。開発環境用にt2シリーズも欲しいですねぇ…。 MySQL 5.6からのマイグレーション マイグレーションには2つの選択肢があります。1つ目は「mysqldump & mysqlimport」、単純にダンプして、それをAuroraに食わせればいいんですね。見た目にも分かりやすいです。 もう一つはMySQLのDBスナップショットからAuroraのインスタンスを立てることもできるようです。これは簡単。 制限事項としては2つ。MyISAMエンジンを使っている場合は、予めInnoDBに変換しておく必要があります。そもそもRDS for MySQLでは推奨されていなかったエンジ
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
今回は、まだ全然底が見えていないAuroraのガチンコ検証となります。公式資料に、発表当初の簡単な検証数値もありますが、自分でやらないと理解できない部分が多くあるためです。 既にAuroraにするだけで従来より速くなる説は有力ですが、なぜ速くなるのか、どのような点に注意を払って運用すべきなのか、といったことを理解するために、より局所的な検証をいくつか行って考察していきたいと思います。 目次 楽しい検証になって長くなりましたので、目次を置いておきます。 はじめに クエリのレスポンスタイム クエリキャッシュ CPU利用率とIOPSの性質 データ容量とストレージ性能の関係 インスタンスタイプとストレージ性能の関係 運用面の色々 何がボトルネックになるか はじめに いくつか前提的なものを。 ベンチマークは全て、sysbench を使ってテストデータ作成・ランダム参照/更新クエリを実行しています デ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く