AWS DMSを使ってRDS for PostgresからDynamoDBにデータ移行

はじめに

Postgresqlに保存してあったデータをDynamoDBに移行させるために、AWSのDMS(Database Migration Service)を使ってみた時の、メモをまとめた記事である。

背景

クローリングしたデータをRDS for Postgresqlに保存していて、そのデータの利用してAPI GatewayとLambdaを使ってAPIサーバを作成しようと思っていたのだが、RDSとLambdaは相性が良くないということが判明した(接続数の問題などで)。
しかも、DynamoDBを使えば、エンドポイントがつくられるので、わざわざLambdaで関数作る必要無いことに気がついたので、RDS to DynamoDBへの移行計画を立てることにした。

調べているとAWS DMSという、いかにもなサービスがあったので使ってみることにしたというのが、事の顛末である。

AWS DMSについて

AWS DMS(Database Migration Service)は、Databaseの移行を簡単に行えるサービスである。
Mysql to Mysqlのような同種DB間のデータ移行にも当然対応しているが、Postgresql to DynamoDBのような異種DB間のデータ移行にも対応している。
利用シーンとしては、オンプレのMySQLサーバをRDS for MySQLに移行する際や、RDS for PostgresqlをAurora for Postgresqlに移行する際に使用する。
また、一度だけのデータ移行にも使えるが、継続的なレプリケーションにも対応しているので、開発/テスト環境の同期などにも使うことができる。
ちなみに、Aurora、Redshift、DynamoDBに移行する場合はDMSを6ヶ月間無料で使うことができる。今回はDynamoDBに移行させるので、試すにはピッタリだった。

移行手順

1. レプリケーションインスタンスの作成

DMSでデータ移行するためにはレプリケーション用のインスタンスを作成する必要がある。
これは、DMSの設定画面から簡単に設定できる。

AWSコンソールから
「Database Migration Service >> レプリケーションインスタンス >> レプリケーションインスタンスの作成」
を選択。

すると以下のような画面が出てくる。
image.png

  • 名前:

    • レプリケーションインスタンスの名前
  • 説明:
    • レプリケーションインスタンスの説明
  • インスタンスクラス:
    • EC2でいうインスタンスタイプ
    • 2018年1月現在ではt2とc4インスタンスが選べる
    • 料金はこちら
  • レプリケーションエンジンのバージョン:
    • バージョン2.4.0を選択するとデータの検証ができるらしい
    • 古いものを選ぶ理由は今のところ無いので新しいバージョンを選ぶ
  • vpc:
    • レプリケーションインスタンスを置くvpc
    • 移行元か移行先どちらかのvpcに置くと色々と楽
      • ちなみに、移行元か移行先のどちらかがAWSサービスでないとDMSは使用できない
  • マルチAZ:
    • レプリケーションインスタンスをマルチAZ配置にする場合有効にする
  • パブリックアクセス可能:
    • レプリケーションインスタンスをインターネットアクセス可能にする場合有効にする
    • VPCでサブネットやインターネットゲートウェイをしっかりと設定しているのであれば有効にする必要がない(はず)

2. ソースエンドポイントの作成

ソースエンドポイントでは移行元のDBへのアクセス方法を設定する。
今回はRDS for Postgresqlが移行元DBになる。

AWSコンソールから
「Database Migration Service >> エンドポイント >> エンドポイントの作成」
を選択。

すると以下のような画面が出てくる
image.png

  • エンドポイントタイプ:

    • ソースかターゲットを選択
    • 移行元がソースなので、ここではソースを選択
  • エンドポイント識別子:
    • 作成するエンドポイントの名前
    • 同じ名前のエンドポイントは作成できない
    • 名前が同じでなければなんでも良い
  • ソースエンジン:
    • 移行元のデータベースエンジン
    • 今回はPostgresqlなので、postgesを選択
  • サーバ名:
    • 移行元のサーバ名
    • オンプレの場合であれば、そのサーバのアドレス
    • RDSであれば、インスタンスのエンドポイントを入力すれば良い
  • ポート:
    • 移行元DBのポート番号
    • 今回はPostgresのデフォルトポートの5432を入力
  • SSLモード:
    • 移行時の通信を暗号化するかを選択する
    • SSLを有効にした場合には、安全にはなるがオーバーヘッドが増えるので必要化判断して有効化すること
    • 選択した項目によりサーバ証明書が必要になる
    • 選択項目は以下の4つ
      • none: 暗号化しない
      • require: 暗号化される。証明書は不要。
      • verify-ca: 暗号化される。証明書が必要。
      • verify-full: 暗号化される。証明書とサーバのホスト名が一致するか確認される
  • ユーザ名
    • 移行元DBのユーザー名
    • ここでマスターユーザを選択しないと色々と面倒なので、マスターユーザを選択すること
  • パスワード
    • 先程選択したユーザのパスワード
    • 「&」や「+」のような記号はエスケープしないと使えない
    • 「&」や「+」が入る場合は全てを波括弧「{}」で括ること
  • データベース名
    • 移行したいデータベース名

一通りの設定をした後、接続テストができる。
ここで接続する元は、先程作成したレプリケーションインスタンスになるため、セキュリティーグループやファイアーウォールでアクセス制限をしている場合は、レプリケーションインスタンスがアクセスできるようにする必要がある。

3. ターゲットエンドポイントの作成

こちらでは移行先のDBのアクセス方法を設定する。
今回の移行先はDynamoDBになる。

設定方法は基本的にソースエンドポイントと同じだが、ターゲットエンドポイントにDynamoDBを設定した場合には、サービスのアクセスロールだけ指定すれば簡単に設定することができる。

AWSコンソールから
「Database Migration Service >> エンドポイント >> エンドポイントの作成」
を選択。

エンドポイントタイプをターゲットを選択し、ターゲットエンジンをDynamoDBにすると、以下のような画面が出てくる。
image.png

  • エンドポイント識別子:

    • エンドポイントの名前
    • 既に作成済みのエンドポイントと重複しなければ良い
  • ターゲットエンジン:
    • 移行先のデータベース
    • 今回はdynamodbを選択
  • サービスへのアクセスロールのARN
    • DynamoDBのアクセス権限があるIAM RoleのARN
    • ポリシーは細かく設定できるけど、めんどくさかったので以下のポリシーをアタッチ
      • AmazonDynamoDBFullAccess
      • AmazonDMSVPCManagementRole(いらないかも…?)

これも、必ず接続テストを行うこと。
DynamoDBに関しては、設定したロールが正しいアクセス権限を持っていれば問題なく接続できる(はず)

4. タスクの作成

移行するための最後の設定としてタスクを作成する。

AWSコンソールから
「Database Migration Service >> タスク >> タスクの作成」
を選択。

すると以下のような画面が出てくる。タスクの設定だけはちょっと長いので分割して説明する。
image.png

  • タスク名:

    • タスクの名前
    • これはなんでも良い
  • レプリケーションインスタンス:
    • このタスクで使用するレプリケーションインスタンス
    • 今回は 1. で作成したものを使用する
  • ソースエンドポイント:
    • このタスクの移行元となるエンドポイント
    • 今回は 2. で作成したものを使用する
  • ターゲットエンドポイント:
    • このタスクの移行先となるエンドポイント
    • 今回は 3. で作成したものを使用する
  • 移行タイプ:
    • このタスクで継続的にデータのレプリケーションを行うか設定する
    • 項目は以下の3つ
      • 既存のデータを移行する

        • 初回の移行のみ実行する
      • 既存のデータを移行し、継続的な変更をレプリケートする
        • 初回の移行を実行し、その後も継続的にレプリケートされる
      • データ変更のみをレプリケートする
        • データ変更のみをレプリケートされる
        • 通常、同種DB間の移行にのみ適用されるらしい
        • どういう時に使うかはよくわからなかった
    • 今回は、一度だけ移行ができれば良いので、「既存のデータを移行する」を選択
  • 作成時にタスクを実行
    • タスクの作成と同時にタスクを実行したければチェックをつける

次はタスク設定の画面
image.png

  • ターゲットテーブル作成モード:

    • タスク実行時に移行先のテーブルをどうするかを設定する
    • 設定項目は以下の3つ
      • 何もしない

        • 移行先にテーブルがない場合作られる
      • ターゲット上のテーブルをDROP
        • 移行先のテーブルを全部DROPする
      • TRUNCATE
        • メタデータに影響を与えないよう、TRUNCATEされる
  • レプリケーションにLOB列を含める:
    • データ移行の際にLOB(Large Object)を含めるか設定する
    • 画像をバイナリで保存している際などに、そのデータを移行するか設定する
    • 以下の設定項目がある
      • LOB列を含めない

        • LOB列を移行対象から外す
      • 完全LOBモード
        • サイズに関係なくLOB列を移行対象に含める
        • チャンク単位で送信するため、低速
      • 制限付きLOBモード
        • 次で設定する最大LOBサイズ以上のデータを削除して送信する
        • 完全LOBモードに比べると高速
  • 最大LOBサイズ(KB):
    • レプリケーションにLOB列を含めるに制限付きLOBモードを選択した時の最大LOBサイズ
  • 検証の有効化:
    • 移行元と移行先でデータを比較し検証するかどうかを選択する
  • ロギングの有効化:
    • 移行時のログをCloudWatch Logsに吐くかを選択する

最後にテーブルマッピングの設定
image.png

  • 選択ルールを設定する。
  • このルールに基いて、除外するテーブルやカラムを決定する。
  • ワイルドカードを使用できるので、まぁまぁ柔軟に設定できそう。
  • 最低一つは設定しなければいけないっぽい。
  • 一旦、デフォルトの状態のまま選択ルールの追加する。
  • 選択ルールを一つでも追加すると、変換ルールも追加できるようになる。
    • 名前の変更とか、テーブルや列の削除しかできないので、結構限定的。

以上が全て設定できたら、タスクの作成ボタンを押下。
「作成時にタスクを開始」にチェックが入っている場合にはすぐにタスクが実行される。

所感

実際にAWS DMSを使ってみて、かなり簡単に異種DB間のデータ移行を実現することができた。
データ量もあまり多くなかったため、10分程度で全てのデータ移行が完了していた。
コストも今回は無料だったし、実際に課金されても低コストで使用することができそう。

実際にDynamoDBを見てみるとPostgresqlにあったテーブルが作成されていた。
しかし、いくつかカラムが消えていたので、まだ調査が必要そうだ(LOB列と判断された…?)。

参考

続きを読む

meltdownのパッチでAWSのPostgreSQLがやられた

この脆弱性が緊急度が高く、Azure、AWSなど一部クラウド環境には事前にパッチが適用されたのだが、そのパッチが担当システムにて影響がでてサーバ自体がダメになってしまったのだ。やっと今日すべて事業が通常に戻ったので久方ぶりにビール飲みつつこれを書いている。 原因と結果を端的に書くとこれだけ。ただ仕事と … 続きを読む

AWSとAzureとGCPを比較してみる – DB編

DBについて、AWSとAzureとGCPを比較してみました。

1. 新世代DB

AWS Azure GCP
新世代DB Aurora Cosmos DB Cloud Spanner
DBの種類 MySQL,
Postgresql
SQL (document DB),
MongoDB (document DB),
Gremlin (graph DB),
Azure Table(KVS),
Cassandra
オリジナルのリレーショナルDB
サーバレスか否か サーバあり サーバレス サーバレス
高可用性構成 / 負荷分散 Auroraレプリカ,
クロスリージョンレプリカ(MySQLのみ)
リージョン間フェイルオーバー,
予約済みスループット
リージョン内レプリケーション,
マルチリージョンレプリケーション
地理的範囲 リージョン(MySQLは別リージョンにレプリケーション可) グローバル グローバル
マルチマスター シングルマスター,
マルチマスター*
マスターになるリージョンは1個 マルチマスター

*プレビュー

DBの種類ですが、Auroraは手堅くMySQLとPostgresql、Cosmos DBはバラエティーにとんでいてドキュメントDB・KVS・グラフDBとCassandra、Cloud SpannerはオリジナルのリレーショナルDBとなっています。
Cloud Spannerはクライアントライブラリが各言語(C#,GO,Java**, node.js**,PHP**, Python**, Ruby)に対し用意されていますが、ORMの対応が気になるところです。
**ベータ

Cosmos DBとCloud Spannerはサーバレスですが、Auroraはインスタンスタイプを指定してインスタンスを構築します。また、拡張機能というよりは別物として、サーバレスタイプのAurora serverless*がプレビュー中です。

高可用性構成と負荷分散ですが、Auroraはリージョン内ではリードレプリカが障害時にマスターに昇格することで対応しています。MySQL版はクロスリージョンレプリケーション構成を取ることができますが、リージョン間で自動フェイルオーバーする仕組みはありません。
また、Auroraはマルチマスター機能であるAurora Multi-Master*が現在プレビュー中ですが、リージョン間でも利用可能になる予定があるとアナウンスされています。リリースされればグローバルで高可用性と負荷分散が簡単に実現できそうです。
Cosmos DBは、1個の書き込みリージョンを持つリージョン間フェイルオーバー***の仕組みで高可用性を実現しています。
Cloud Spannerはリージョン内レプリケーションとマルチリージョンレプリケーションの仕組みで高可用性を実現しています。1つのリージョンで構築する場合は、3個のread-writeレプリカを保持します。複数リージョンで構築する場合は、2個のread-writeレプリカを保持する2個のread-writeリージョン(と場合によってread-onlyリージョン)で構成されます。

***Microsoftのドキュメントではregional failoverをリージョン内フェイルオーバーと訳していますが、意味合いはリージョン間フェイルオーバーなので、ここではそのように表記しています。

2. リレーショナルDB

AWS Azure GCP
MYSQL互換 MySQL
/ MariaDB
Azure Database for MySQL* Google Cloud SQL for MySQL
高可用性構成 Multi-AZ,
クロスリージョンリードレプリカ
フェイルオーバーレプリカ
負荷分散 リードレプリカ,
クロスリージョンリードレプリカ
リードレプリカ
Postgresql Postgresql Azure Database for PostgreSQL* Google Cloud SQL for PostgreSQL**
高可用性構成 Multi-AZ,
クロスリージョンリードレプリカ
リージョナルインスタンス**
負荷分散 リードレプリカ,
クロスリージョンリードレプリカ
リードレプリカ**
SQL Server SQL Server Azure SQL Database
高可用性構成 Multi-AZ アクティブgeoレプリケーション
負荷分散 アクティブgeoレプリケーション
Oracle Oracle
高可用性構成 Multi-AZ
負荷分散

*プレビュー
**ベータ

・各クラウド間での違い-その1

AWSのMulti-AZとGCPのリージョナルインスタンス(PostgreSQL)は、スタンバイ側はリードの機能がないので負荷分散には利用できませんが、GCPのフェイルオーバーレプリカ(MySQL)はリードの機能があるので負荷分散にも利用できます。

3. NOSQL

AWS Azure GCP
KVS・ドキュメント ElastiCache(Memcached, Redis),
DynamoDB
Redis Cache,
Cosmos DB(Azure Table, SQL, MongoDB)
Cloud Datastore,
Cloud Bigtable
グラフ Neptune* Cosmos DB(Gremlin)
Cosmos DB(Cassandra)

*プレビュー

Neptuneの現時点のプレビューのAWSマネジメントコンソール画面はAmazon RDSとよく似ています。また裏でAuroraと同じ仕組みを利用しているそうなので、ひょっとしたらCosmos DBみたいに、Auroraの一機能としてリリースされるかも知れません。

4. まとめ

現在は、MySQL・Postgresqlを利用したければAWSのAuroraかRDS、SQL Serverを利用したければAzureでしょうか。
ただ各クラウドのプレビュー・ベータ提供状況を見ていると、そのうち機能差は無くなるように思えます。

続きを読む

Amazon Linux(EC2)上にRedashをセットアップする

公式のAMIだとUbuntu系なのと
できればAmazon Linuxで保守メンテしたいと思っていたので公式のsetupスクリプトを参考にセットアップしてみた。

cf. 公式でDeprecatedになってるセットアップのバッシュファイル
https://github.com/getredash/redash/blob/master/setup/amazon_linux/bootstrap.sh

EC2の初期セットアップ

EC2の初期セットアップはこちらから。
https://qiita.com/kazupyong/items/8d05c8421db37dcf06c9

公式からソースコードをDLする

https://github.com/getredash/redash/tree/v3.0.0
2018/01/01時点での最新安定バージョンは3.0.0+b3134でした。
(最近までタグが切られてなかった気が、、、)

cd /opt/redash
wget https://github.com/getredash/redash/archive/v3.0.0.zip
unzip v2.0.1.zip
ln -s redash-2.0.1 current
cd current

必要なライブラリのインストール

上のスクリプトを参考に各種必要なライブラリとかをセットアップする。

sudo yum update
sudo yum upgrade
sudo yum install -y python-pip python-dev nginx curl build-essential pwgen  libffi-dev libssl-dev libmysqlclient-dev libpq-dev freetds-dev libsasl2-dev xmlsec1 postgresql redis-server
sudo yum install gcc librdkafka1 librdkafka-devel cyrus-sasl-devel

envファイルを設置

設定の参考スクリプトは公式のUbuntuのセットアップスクリプトから持ってくる。

cd
wget https://raw.githubusercontent.com/getredash/redash/master/setup/ubuntu/files/env
ln -s env current/.env
COOKIE_SECRET=$(mkpasswd -l 32 -s 0)
echo "export REDASH_COOKIE_SECRET=$COOKIE_SECRET" >> env
export REDASH_NAME="Redash"
export REDASH_STATIC_ASSETS_PATH="../rd_ui/dist/"
export REDASH_LOG_LEVEL="INFO"
export REDASH_REDIS_URL=redis://localhost:6379/0
export REDASH_DATABASE_URL="postgresql:///redash"

設定値一覧はこちらを参考に
cf. https://qiita.com/kyoshidajp/items/3528e3cd470eafef6edf

pip update

pipをアップデートでして依存ライブラリをインストール。
ビルドには少し時間がかかる。

sudo /usr/local/bin/pip install --upgrade pip
sudo /usr/local/bin/pip install -r ./requirements.txt
sudo /usr/local/bin/pip install -r ./requirements_all_ds.txt

postgresql setup

postgresqlをインストール。
Redash内部ではpostgresqlを使っている。

sudo -u postgres createuser redash --no-superuser --no-createdb --no-createrole
sudo -u postgres createdb redash --owner=redash

初期のDBをセットアップ

cd /opt/redash/current
sudo -u redash bin/run ./manage.py database create_tables

setup supervisord

Redashはsupervisord経由で動いているのでインストールしてセットアップする。
詳し説明は以下に書いてあります。
https://qiita.com/kazupyong/items/d576b95ab9c7e3800b30

npm 設定

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.29.0/install.sh | bash
nvm install v6.11
nvm use 6.11
nvm alias default 6.11
cd current/
npm install
npm run build

nginx 設定

sudo yum install nginx
sudo chkconfig nginx on
wget https://raw.githubusercontent.com/getredash/redash/master/setup/ubuntu/files/nginx_redash_site
sudo mv nginx_redash_site /etc/nginx/conf.d/redash.conf

Google Developer作成

https://console.developers.google.com/apis/library
Google+ APIでOAuth2の認証作成
Client ID XXXX
Secret   XXXX
# 上で取得した値を.envファイルに追記する
export REDASH_GOOGLE_CLIENT_ID="HOGEHOGE"
export REDASH_GOOGLE_CLIENT_SECRET="HOGEHOGE"

これで一通り最低限は動くはずです。

参考にしたサイト

http://help.redash.io/
https://qiita.com/kyoshidajp/items/3528e3cd470eafef6edf

続きを読む

2017年のAzure国内トピックを振り返る

MySQL、PostgreSQL、Maria DBのPaaSは、AWSのAmazon RDSから遅れての登場になりました。マイクロソフトは、サービスの可用性(SLA99.99%)の高さ、バックアップ/リストア機能の標準内蔵といった競合優位性をアピールし、PostgreSQLの利用が多い日本市場や、国策でクラウドDBの利用がOSSのみに制限される … 続きを読む

“イシイサン”が「AWS re:Invent 2017」

クラウド時代にPostgreSQLはどう進化する? 世界の”イシイサン”が「AWS re:Invent 2017」で示したPostgreSQLの方向性:レポート|gihyo.jp … 技術評論社. 「今回, この場ですばらしいゲストをお迎えできることを心から嬉しく思う。18年にも渡ってPostgreSQL開発者として活動をされてきたPostgreSQLの世界的リーダーの” … 続きを読む

AWS Cloud9 で Ruby on Rails を試してみた

2017/11/30にAWSにて、クラウド型統合IDE Cloud9がローンチされましたので。
さっそく、Railsアプリケーションで試してみました。
AWS Cloud9 – クラウド開発環境

今回使用した環境

クライアントPC:mac book pro
ブラウザ:chrome
AWS使用サービス:
 CodeStar、EC2(t2.micro)、Cloud9

前提

以下の手順は、IAMユーザで行っています。
AWSは、ルートアカウントとは別に管理アカウントを複数作成できます。
これらのアカウントをAWSでは、IAMユーザと呼んでいる様ですが、
こうして作成した、IAMユーザは、クレジット情報などへの
アクセスをさせずに、管理業務だけを委任したりできるため、大変便利です。
AWS アカウント内での IAM ユーザーの作成

CodeStarによる環境セットアップ

まず、EC2にnginx+railsの環境を作成するため、CodeStarを使用します。
EC2のインスタンスを起動して一から必要なものをインストールしても良いのですが、
CodeStar使用すると、その辺の事をよしなにやってくれます。

まず、キーペアがひとつ必要です。
無い場合は、下記の手順で作成しておきます。
Amazon EC2 のキーペア

作成し終えたら、CodeStarのコンソールにアクセスします。
AWSにログインした状態で、以下のアドレスです。
CodeStarコンソール

スクリーンショット 2017-12-19 22.34.37.png

「Start a project」をクリックして、テンプレート選択画面に遷移しましょう。

スクリーンショット 2017-12-19 22.37.31.png

作成可能なテンプレートがたくさん並んでいます。
Railsに関しては、AWS Elastic Beanstalk版とEC2版がありますが、
今回は、簡易的な動作確認ですので、EC2版を選択します。
おそらく、Sqlite3を使った1インスタンスの最小構成で作成されるはずです。
mysqlなどのRDBを使ったり、ロードバランサを置いたりしたい場合は、
AWS Elastic Beanstalk版を選択すると良いと思います。

次はプロジェクト名とリポジトリ名を入力します。

スクリーンショット 2017-12-19 22.44.17.png

両方ともに「RailsSample」にしました。
リポジトリ管理には、AWS CodeCommit か GitHub のどちらかを選択できます。
どちらを選んでも、Gitでのバージョン管理になります。
CodeCommitは、GitHubの簡易版の様な位置づけでしたが、
2017年11月には、pullリクエストの作成もサポートされたらしく
徐々に使える様になってきている感じでしょうか。

今回は、CodeCommitを選択しました。

Create Project を選択すると、キー選択画面がポップアップされますので、
はじめに作成したキーペアを選択します。

スクリーンショット 2017-12-19 22.55.12.png

使用するIDEを選択する画面になりました。
ここで、本題のAWS Cloud9が出てきます。

スクリーンショット 2017-12-19 22.57.18.png

ここは当然、Cloud9を選択してみました。

スクリーンショット 2017-12-19 23.00.43.png

Cloud9を動作させるためのインスタンスの種類を選択します。
無料枠で試すには、t2.micro を選択します。

スクリーンショット 2017-12-19 23.03.24.png

環境の準備中です。
至るところクルクルしてますので、
しばし、待ちます。(5分くらいかな…)

スクリーンショット 2017-12-19 23.10.37.png

デプロイステータスが上記の様になり、
ヘッダ部が以下の様に変わったら、準備OKだと思います。

スクリーンショット 2017-12-19 23.12.29.png

View your app でRailsのサンプル・アプリケーションにアクセスできます。

スクリーンショット 2017-12-19 23.14.42.png

しゃれおつ。

Start coding の方を選択すると、Cloud9の画面に遷移します。

AWS Cloud9

スクリーンショット 2017-12-19 23.23.59.png

IDEっぽいです。
ブラウザだけでこれだけできるなんて、時代が進んだのを感じます。

ディレクトリツリーを見ると、Railsっぽい環境になっているのがわかります。
下部のペインは、EC2のコンソールになっていて、
シェルコマンドはここから実行できます。

RailsUser01:~/environment/railssample (master) $ ruby -v
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
RailsUser01:~/environment/railssample (master) $ gem list

*** LOCAL GEMS ***

actioncable (5.1.4)
actionmailer (5.1.4)
actionpack (5.1.4)
actionview (5.1.4)
activejob (5.1.4)
activemodel (5.1.4)
activerecord (5.1.4)
activesupport (5.1.4)
arel (8.0.0)
bigdecimal (default: 1.3.0)
builder (3.2.3)
bundler (1.15.4)
bundler-unload (1.0.2)
concurrent-ruby (1.0.5)
crass (1.0.2)
did_you_mean (1.1.0)
erubi (1.7.0)
executable-hooks (1.3.2)
gem-wrappers (1.3.2)
globalid (0.4.1)
i18n (0.9.0)
io-console (default: 0.4.6)
json (default: 2.0.2)
loofah (2.1.1)
mail (2.6.6)
method_source (0.9.0)
mime-types (3.1)
mime-types-data (3.2016.0521)
mini_portile2 (2.3.0)
minitest (5.10.1)
net-telnet (0.1.1)
nio4r (2.1.0)
nokogiri (1.8.1)
openssl (default: 2.0.3)
power_assert (0.4.1)
psych (default: 2.2.2)
rack (2.0.3)
rack-test (0.7.0)
rails (5.1.4)
rails-dom-testing (2.0.3)
rails-html-sanitizer (1.0.3)
railties (5.1.4)
rake (12.0.0)
rdoc (default: 5.0.0)
rubygems-bundler (1.4.4)
rvm (1.11.3.9)
sprockets (3.7.1)
sprockets-rails (3.2.1)
test-unit (3.2.3)
thor (0.20.0)
thread_safe (0.3.6)
tzinfo (1.2.3)
websocket-driver (0.6.5)
websocket-extensions (0.1.2)
xmlrpc (0.2.1)

現環境では、rubyは2.4.1、railsは、5.1.4の様です。
何か機能を足してみましょう。

RailsUser01:~/environment $ cd ./railssample
RailsUser01:~/environment/railssample (master) $ rails g scaffold blog title:string body:text
Usage:
  rails new APP_PATH [options]

Options:
  -r, [--ruby=PATH]                                      # Path to the Ruby binary of your choice
                                                         # Default: /usr/local/rvm/rubies/ruby-2.4.1/bin/ruby
  -m, [--template=TEMPLATE]                              # Path to some application template (can be a filesystem path or URL)
  -d, [--database=DATABASE]                              # Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)

...以下略

おや?
エラーです。。。Usageが出ますね。。。

お気付きでしょうか?
ディレクトリツリーを見てわかる様にbinフォルダが存在しませんね。。。
なぜかは、わかりませんが、
rakeで作成できるはずなので、やってみます。

RailsUser01:~/environment/railssample (master) $ rake app:update:bin
Could not find gem 'passenger' in any of the gem sources listed in your Gemfile.
Run `bundle install` to install missing gems.

ん?
gem ‘passenger’ がいない?
確かに前述の gem list とGemfileの内容が一致していない様に思います。

bundle isntall します。

RailsUser01:~/environment/railssample (master) $ bundle install
The dependency tzinfo-data (>= 0) will be unused by any of the platforms Bundler is installing for. Bundler is installing for ruby but the dependency is only for x86-mingw32, x86-mswin32, x64-mingw32, java. To add those platforms to the bundle, run `bundle lock --add-platform x86-mingw32 x86-mswin32 x64-mingw32 java`.
Fetching gem metadata from https://rubygems.org/.........
Fetching version metadata from https://rubygems.org/..
Fetching dependency metadata from https://rubygems.org/.
Resolving dependencies...
Fetching rake 11.2.2
Installing rake 11.2.2
Fetching concurrent-ruby 1.0.2
Installing concurrent-ruby 1.0.2
Fetching i18n 0.7.0
Installing i18n 0.7.0
Fetching minitest 5.9.0
Installing minitest 5.9.0
Fetching thread_safe 0.3.5
Installing thread_safe 0.3.5
Fetching builder 3.2.2
Installing builder 3.2.2
Fetching erubis 2.7.0
Installing erubis 2.7.0
Fetching mini_portile2 2.1.0
Installing mini_portile2 2.1.0
Fetching pkg-config 1.1.7
Installing pkg-config 1.1.7
Fetching rack 2.0.1
Installing rack 2.0.1
Fetching nio4r 1.2.1
Installing nio4r 1.2.1 with native extensions
Using websocket-extensions 0.1.2
Using mime-types-data 3.2016.0521
Fetching arel 7.1.1
Installing arel 7.1.1
Using bundler 1.15.4
Fetching byebug 9.0.5
Installing byebug 9.0.5 with native extensions
Fetching coffee-script-source 1.10.0
Installing coffee-script-source 1.10.0
Fetching execjs 2.7.0
Installing execjs 2.7.0
Fetching method_source 0.8.2
Installing method_source 0.8.2
Fetching thor 0.19.1
Installing thor 0.19.1
Fetching debug_inspector 0.0.2
Installing debug_inspector 0.0.2 with native extensions
Fetching ffi 1.9.14
Installing ffi 1.9.14 with native extensions
Fetching multi_json 1.12.1
Installing multi_json 1.12.1
Fetching libv8 3.16.14.19 (x86_64-linux)
Installing libv8 3.16.14.19 (x86_64-linux)
Fetching rb-fsevent 0.9.7
Installing rb-fsevent 0.9.7
Fetching puma 3.0.0
Installing puma 3.0.0 with native extensions
Fetching ref 2.0.0
Installing ref 2.0.0
Fetching sass 3.4.22
Installing sass 3.4.22
Fetching tilt 2.0.5
Installing tilt 2.0.5
Fetching spring 1.7.2
Installing spring 1.7.2
Fetching sqlite3 1.3.11
Installing sqlite3 1.3.11 with native extensions
Fetching turbolinks-source 5.0.0
Installing turbolinks-source 5.0.0
Fetching tzinfo 1.2.2
Installing tzinfo 1.2.2
Fetching nokogiri 1.6.8
Installing nokogiri 1.6.8 with native extensions
Fetching rack-test 0.6.3
Installing rack-test 0.6.3
Fetching passenger 5.1.12
Installing passenger 5.1.12 with native extensions
Fetching sprockets 3.7.0
Installing sprockets 3.7.0
Fetching websocket-driver 0.6.4
Installing websocket-driver 0.6.4 with native extensions
Using mime-types 3.1
Fetching coffee-script 2.4.1
Installing coffee-script 2.4.1
Fetching uglifier 3.0.1
Installing uglifier 3.0.1
Fetching rb-inotify 0.9.7
Installing rb-inotify 0.9.7
Fetching therubyracer 0.12.3
Installing therubyracer 0.12.3 with native extensions
Fetching turbolinks 5.0.0
Installing turbolinks 5.0.0
Fetching activesupport 5.0.0
Installing activesupport 5.0.0
Fetching loofah 2.0.3
Installing loofah 2.0.3
Fetching mail 2.6.4
Installing mail 2.6.4
Fetching listen 3.0.5
Installing listen 3.0.5
Fetching rails-dom-testing 2.0.1
Installing rails-dom-testing 2.0.1
Fetching globalid 0.3.7
Installing globalid 0.3.7
Fetching activemodel 5.0.0
Installing activemodel 5.0.0
Fetching jbuilder 2.5.0
Installing jbuilder 2.5.0
Using rails-html-sanitizer 1.0.3
Fetching spring-watcher-listen 2.0.0
Installing spring-watcher-listen 2.0.0
Fetching activejob 5.0.0
Installing activejob 5.0.0
Fetching activerecord 5.0.0
Installing activerecord 5.0.0
Fetching actionview 5.0.0
Installing actionview 5.0.0
Fetching actionpack 5.0.0
Installing actionpack 5.0.0
Fetching actioncable 5.0.0
Installing actioncable 5.0.0
Fetching actionmailer 5.0.0
Installing actionmailer 5.0.0
Fetching railties 5.0.0
Installing railties 5.0.0
Fetching sprockets-rails 3.1.1
Installing sprockets-rails 3.1.1
Fetching coffee-rails 4.2.1
Installing coffee-rails 4.2.1
Fetching jquery-rails 4.1.1
Installing jquery-rails 4.1.1
Fetching web-console 3.3.1
Installing web-console 3.3.1
Fetching rails 5.0.0
Installing rails 5.0.0
Fetching sass-rails 5.0.6
Installing sass-rails 5.0.6
Bundle complete! 17 Gemfile dependencies, 67 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.

入ったっぽい。
再度、rakeにトライ。
今度は。bundle execつき

RailsUser01:~/environment/railssample (master) $ bundle exec rake app:update:bin                                                                               
/usr/local/rvm/gems/ruby-2.4.1/gems/rake-11.2.2/lib/rake/ext/fixnum.rb:4: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:206: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:51: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:52: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:47: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:51: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:110: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:111: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
      create  bin
      create  bin/bundle
      create  bin/rails
      create  bin/rake
      create  bin/setup
      create  bin/update
RailsUser01:~/environment/railssample (master) $ 

できた。
再度、scaffold。

RailsUser01:~/environment/railssample (master) $ rails g scaffold blog title:string body:text
/usr/local/rvm/gems/ruby-2.4.1/gems/rake-11.2.2/lib/rake/ext/fixnum.rb:4: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:206: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:51: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:52: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:47: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:51: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:110: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:111: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/core_ext/numeric/conversions.rb:138: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
      invoke  active_record
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
      create    db/migrate/20171219144809_create_blogs.rb
      create    app/models/blog.rb
      invoke    test_unit
      create      test/models/blog_test.rb
      create      test/fixtures/blogs.yml
      invoke  resource_route
       route    resources :blogs
      invoke  scaffold_controller
      create    app/controllers/blogs_controller.rb
      invoke    erb
      create      app/views/blogs
      create      app/views/blogs/index.html.erb
      create      app/views/blogs/edit.html.erb
      create      app/views/blogs/show.html.erb
      create      app/views/blogs/new.html.erb
      create      app/views/blogs/_form.html.erb
      invoke    test_unit
      create      test/controllers/blogs_controller_test.rb
      invoke    helper
      create      app/helpers/blogs_helper.rb
      invoke      test_unit
      invoke    jbuilder
      create      app/views/blogs/index.json.jbuilder
      create      app/views/blogs/show.json.jbuilder
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/blogs.coffee
      invoke    scss
      create      app/assets/stylesheets/blogs.scss
      invoke  scss
      create    app/assets/stylesheets/scaffolds.scss
RailsUser01:~/environment/railssample (master) $ 

migrateも成功。

RailsUser01:~/environment/railssample (master) $ bundle exec rails db:migrate
/usr/local/rvm/gems/ruby-2.4.1/gems/rake-11.2.2/lib/rake/ext/fixnum.rb:4: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:206: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:51: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/xml_mini.rb:52: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:47: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/digest_utils.rb:51: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:110: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/sprockets-3.7.0/lib/sprockets/processor_utils.rb:111: warning: constant ::Bignum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/activesupport-5.0.0/lib/active_support/core_ext/numeric/conversions.rb:138: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
== 20171219144809 CreateBlogs: migrating ======================================
-- create_table(:blogs)
   -> 0.0009s
== 20171219144809 CreateBlogs: migrated (0.0017s) =============================

/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated
/usr/local/rvm/gems/ruby-2.4.1/gems/concurrent-ruby-1.0.2/lib/concurrent/map.rb:230: warning: constant ::Fixnum is deprecated

このまま、コミットして、masterにpushします。

RailsUser01:~/environment/railssample (master) $ git add .
RailsUser01:~/environment/railssample (master) $ git commit -m 'blogs追加'
[master c39da40] blogs追加
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

 28 files changed, 454 insertions(+), 1 deletion(-)
 create mode 100644 app/assets/javascripts/blogs.coffee
 create mode 100644 app/assets/stylesheets/blogs.scss
 create mode 100644 app/assets/stylesheets/scaffolds.scss
 create mode 100644 app/controllers/blogs_controller.rb
 create mode 100644 app/helpers/blogs_helper.rb
 create mode 100644 app/models/blog.rb
 create mode 100644 app/views/blogs/_form.html.erb
 create mode 100644 app/views/blogs/edit.html.erb
 create mode 100644 app/views/blogs/index.html.erb
 create mode 100644 app/views/blogs/index.json.jbuilder
 create mode 100644 app/views/blogs/new.html.erb
 create mode 100644 app/views/blogs/show.html.erb
 create mode 100644 app/views/blogs/show.json.jbuilder
 create mode 100755 bin/bundle
 create mode 100755 bin/rails
 create mode 100755 bin/rake
 create mode 100755 bin/setup
 create mode 100755 bin/update
 create mode 100644 db/migrate/20171219144809_create_blogs.rb
 create mode 100644 db/schema.rb
 create mode 100644 test/controllers/blogs_controller_test.rb
 create mode 100644 test/fixtures/blogs.yml
 create mode 100644 test/models/blog_test.rb
 create mode 100644 tmp/restart.txt
RailsUser01:~/environment/railssample (master) $ git config --global user.name "RailsUser01"
RailsUser01:~/environment/railssample (master) $ git config --global user.email test@test.com
RailsUser01:~/environment/railssample (master) $ git push
Counting objects: 47, done.
Compressing objects: 100% (44/44), done.
Writing objects: 100% (47/47), 8.65 KiB | 632.00 KiB/s, done.
Total 47 (delta 7), reused 0 (delta 0)
To https://xxxxx/v1/repos/RailsSample
   01dc390..c39da40  master -> master

すると、CodeStarの方で、pushを検知して、再びデプロイが始まります。
デプロイが終わったら、/blogsでアクセス。

スクリーンショット 2017-12-20 0.01.55.png

できたっぽい。
layoutが、しゃれおつのままなので、逆に見た目がアレですが、
一応、これで、コーディングして行けるっぽいです。

この先のこと

この環境では、EC2(Cloud9開発環境) -> EC2(動作確認環境)にいちいちデプロイして
確認することになるので、ちょっと面倒。
実用的に使うには、EC2(Cloud9開発環境) だけで、動作確認できる様にして、
ステージングやプロダクション環境には、必要に応じてデプロイ出来る様にしたいですね。

EC2(Cloud9開発環境)側にenginxを入れるか、
何かしらの制限付きでpumaのポートを開放するかになるのかな?
まだまだ、いろいろ試せそうな感じですが、
Cloud9ともども、おいおい試していきたいです。

試すだけなら無料枠で出来るので、皆様もいつかの機会にどうでしょうか?
今回はここまでです。

続きを読む

Auroraの拡張性, 可用性について

RDS for MySQLからAuroraに移行した際に調査した拡張性, 可用性の面で優れている点をまとめました。

既存システムの課題

システムの構成はRDS for MySQL Master, Slave 複数台という構成だった。
RDSのスレーブへのコネクションをアプリケーション層で分散していたが, ヘルスチェックし障害が起きていないhealthyなslaveに接続するというチェックができていなかった。

=> 複数Slaveの構成にも関わらず死んでいるSlaveにも接続してしまう つらみ

この課題を解決することをきっかけにより可用性, 拡張性のあるDBの構成を考えるきっかけに。

最初はHAProxyを使用してヘルスチェック, ロードバランシングをしようとしていたがHAProxy自体の冗長化等のコストがあり他の実現方法を調査し, Auroraのリーダーエンドポイントで課題を解決できる
& 可用性, 拡張性の向上が見込めたAuroraへの移行を決めた。

Aurora

可用性, 拡張性にフォーカスして注目すべきところをまとめていきます。

image.png

MySQL/PostgreSQL 互換のリレーショナルデータベースエンジンでパフォーマンス, 可用性、信頼性がRDS for mysqlよりも高いAWSのマネージドデータベースサービス。

Amazon Aurora インスタンスを作成すると、DB クラスターが作成される。
DB クラスターは、1 つ以上のインスタンスと、これらのインスタンスのデータを管理する 1 つのクラスターボリュームで構成されWriter(Master)とReader(Slave)で立ち上がる。
Aurora クラスターボリュームは、複数のアベイラビリティーゾーンにまたがる仮想データベースストレージボリューム。各アベイラビリティーゾーンにはクラスターデータのコピーが格納される。
SSDベースのディスクで10GBから64TBまでダウンタイム無しで自動で拡張される。

インスタンス

プライマリインスタンス

読み取りと書き込みの操作をサポートし、クラスターボリュームに対するすべてのデータ変更を実行する。各 Aurora DB クラスターには 1 つのプライマリインスタンスがある。

Aurora レプリカ

読み取りのみをサポートする。各Aurora DB クラスターは、プライマリインスタンスに加えて最大15 台のレプリカを立ち上げれる。複数のAuroraレプリカはコネクションを分散し、別のアベイラビリティーゾーンにAuroraレプリカを立ち上げることで可用性を上げることができる。

プライマリインスタンスがフェイルオーバーした場合、Aurora レプリカが自動的にプライマリインスタンスに昇格される。尚どのレプリカを指定するかは各レプリカに優先度を設定することができ, 優先度が高いインスタンスからプライマリインスタンスに昇格される。

Auroraには プライマリインスタンス, Aurora レプリカそれぞれを指定するエンドポイントが用意されている。

エンドポイント

クラスターエンドポイント

プライマリインスタンスを指定するエンドポイント。
Read, Writeの両方を実行できる。
インスタンス毎に一意のエンドポイントがあるが, クラスターエンドポイントを利用するとプライマリインスタンスに障害が起きた場合に新しいプライマリインスタンスを参照するようになる。

読み込みエンドポイント

Aurora DB クラスターには読み込みエンドポイントがあり、これを使用して DB クラスターの Aurora レプリカの 1 つに接続できる。DB クラスターの読み込みエンドポイントは、DB クラスター内で使用できる Aurora レプリカ間で接続を負荷分散する。

Aurora DB クラスターで利用できる Aurora レプリカの 1 つに接続する、その DB クラスターのエンドポイント。

明示的にヘルスチェックしているとは言っていない(?)ので注意 :no_good:

インスタンスエンドポイント

プライマリインスタンス, Auroraレプリカのすべての特定のインスタンスに直接接続するためのエンドポイントが用意されている。

Auto Scaling

指定したメトリクスの変更に応じて Aurora レプリカを自動的に追加または削除できるようになった。
CPU 平均使用率や平均アクティブ接続数などの Aurora レプリカの定義済みメトリクスに、必要な値を指定できる。
そのため無駄なコストがかからないようにスケールインすることもできる。

Zero Downtime Patching

私達の、新しいゼロダウンタイムパッチ機能により、Auroraインスタンスへのパッチ適用をダウンタイム無しで、可用性にも影響を及ぼさずオンラインで実行出来るようになりました。この機能は、現在の最新バージョン(1.10)が適用されたAuroraインスタンスで、ベストエフォートで機能します。シングルノードクラスタとマルチノードクラスタのWriterインスタンス双方で機能しますが、バイナリログが有効になっている場合は無効になります。

Multi-Master

つい先日のReinventで発表されたMulti-Master。
クラスタを構成するすべてのノードに対して読み書きが可能になる。

監視項目

Auroraで取れるメトリクス,結構RDSと比較すると監視項目細かく設定できそう。

Mackerelで以下のメトリクスでAuroraの監視している。

Mackerelで監視する項目

  • Queries 1秒あたりに実行されたクエリの平均回数
  • SelectThroughput (per second) 1秒あたりのSELECTの平均回数
  • DMLThroughput (per second) 1秒あたりのINSERT,UPDATE,DELETEの平均回数
  • SelectLatency SELECTクエリのレイテンシー(ミリ秒)
  • DMLLatency INSERT,UPDATE,DELETEのレイテンシー(ミリ秒)
  • Buffer cache hit ratio バッファキャッシュ(バッファプール)のヒット率
  • Deadlocks デッドロック数
  • Blocked Transactions ブロックされているトランザクション数

Migrate back to MySQL

ないとは思うがAuroraに移行し問題がありRDS for MySQLに戻さなければ行けない場合の手順。

https://stackoverflow.com/questions/32794809/is-it-possible-to-migrate-back-from-amazon-aurora-to-native-mysql-in-amazon-rds

Amazon’s Aurora is MySQL wire compatible so you can always use tools such as mysqldump to get your data back out into a form that you could use to import back into a regular MySQL instance running in RDS, an EC2 instance or anywhere else for that matter.

Since posting this answer Amazon has also released the Database Migration Service which can be used to do zero downtime migrations between MySQL -> Aurora MySQL (Aurora also now supports PostgreSQL) and back. It also supports heterogeneous migrations such as from Oracle to Aurora MySQL or a number of other sources and targets.

普通にmysqldump を使ってRDSにデータを移行する。
または, Database Migration Serviceを使用するしかないようだ。

まとめ

Auroraに移行したことで可用性が確実に上がったしパフォーマンス的にネックとなる部分も今は出てきていないので移行は成功だったのではないかと思う。
そしてこれからもAuroraの拡張性, 可用性の部分の改善となるリリースが行われるのではないか。
内部がきになる方はこの記事がとてもわかりやすかったので参考にしていただければ => https://qiita.com/kumagi/items/67f9ac0fb4e6f70c056d

続きを読む