RDS for PostgreSQLを使い始めてみたレポート

PostgreSQL Advent Calendar 2014 の 4日目です。
昨日はNagayasuさんのPostgreSQLカンファレンス2014開催のお知らせと見どころのご紹介 #pgcon14jでした。


　拙作「ふぁぼるっく」 のデータベースをRDS for PostgreSQLへ移行しました。
　一昨日ぐらいに全データを移し終わったところです。
　RDS内部のソフトウェア的なところは、これまでも他の方の記事にあったので、スペック部分に的を当てて書いてみたいと思います。

　それまでは、自宅サーバでよく使うデータやインデックスだけをSSD上のテーブルスペースに置き、あまり参照されないデータなどをHDD上のテーブルスペースで運用していました。今年の5月からVPSのSSDプランを借り、よく使うデータやインデックスだけをVPSのSSDに置いて、残りのデータを自宅サーバに置き、postgresql_fdwで自宅サーバに繋いで利用していましたが、いろいろ問題点が溜まってきました。

• 自宅サーバのSSDがすぐ劣化する（一年ちょっと）
• SSDを買い続けるのと、交換作業の度にバッチを止めたり、回復作業が面倒
  （当時はSSDでRAID 1を組むほどの思い切りがなかった）
• ときどきレプリケーションが失敗してスレーブが止まる
• VPSに移行したが、負荷が高すぎて処理制限を掛けられ、PostgreSQLがOSごと転けた
• 自宅サーバに戻って2TB HDD*5(RAID5)マスターサーバと4TB HDD*2(RAID0)スレーブサーバで組んでみたが、やっぱり速度が出ない

自宅サーバの惨状 ふぁぼ収集サービスのつらみより

気がついたら、コードを書くよりインフラのメンテナンス作業の方に時間を多く取られていることに気がつきました。障害を克服する楽しさが無いとは言いませんが、ソフトウェアでやりたいことが溜まっていくのに、なかなか手がつけられません。ストレスが溜まります。
　ここは、インフラ担当を一人雇うつもりで、全データをRDS for PostgreSQLに移行しました。

db.r3.large インスタンス
General Purpose (SSD) 2000GB

　最終的に、上記の構成になりました。
　当初は、r3.xlargeインスタンスでプロビジョンドIOPSの1000 IOPSにして利用しようと考えていました。100GBの構成でテストしてみたり、料金計算ツールでなんとか払える範囲であることを確認したり・・・。

　最小構成で動くことを確認し、あとは本番用サーバを建てようとしたところ、なにやらエラーが。

2000GB で作るなら、6000 IOPS からだよ。

慌てて料金計算ツールで試算してみたところ、月額10万円以上もの金額！　とても趣味に使える金額ではありません。100GBの時は1000 IOPSからだったのに・・・。

　ふと考えてみると、EC2のEBSはサイズが1TBまででしたので（2014年11月に16TBまでの拡張が発表されました）、3TBまで使えるRDSは内部でEBSを束ねているのだろうと考えられます。
　そうすると、通常のディスクやGeneral Purpose (SSD)でも、ボリュームサイズが大きければ、単体ディスクの時よりスピードが出るのではないか？

動かしてみた。

　移行中に溜まっていた処理を一気に流しているので、かなりギリギリの処理になっていますが、性能が落ちているなー、というときでも400 IOPS程度出ています。
調子の良いときで2000 IOPS、とても良いときで3000 IOPSでました。

db.r3.large インスタンスは、
　vCPU 2
　メモリ 15GB
　ネットワークパフォーマンス 中
　プロビジョンド IOPS用の最適化なし
という条件で、コア数的には自宅サーバやVPS時代と比べて劣っているのですが、ディスクが高速なおかげで、全く遜色を感じません。
こんなことなら、もっと早く移行しておくべきでした。

ということで、速度も巨大ストレージも欲しているデータベースは、RDSでも幸せに運用できるのではないかと思います。
2014年12月現在、3TBまでですが、これもEBSの拡大に合わせて大きくできるのではないかと期待しています。



　ここまで書いておいて、これ単純にAWSの話で、PostgreSQL関係なくね？と気がついたので、やっぱりソフトウェア的な話も。



　RDSへの移行は、しばらく前から考えてはいたのですが、日常的にテーブル間でデータコピーが発生する構成なため、どのように RDS for PostgreSQL を絡めるか、また自宅サーバで1.7TBほどディスクを使っているデータベースをどうやって移行するかが悩みどころでした。

　AWSから出ていくデータには大きなデータ転送量が掛かってしまうため、AWSのサービスを使い始めたら最後、日常的に参照以外でデータをまとめて取り出すことは考えない方がいいでしょう。こうして、それまで組んでいた「よく使うデータはインターネット側、あまり使わない古いデータは自宅サーバ」という構成は諦めることにしました。
　全てのデータを1台のサーバで運用するのは、それまで自宅サーバだけの時代に経験しているので、あとは移行方法です。なるべく動かしたまま移行したいと考えていたところ、タイミング良く11月の更新で移行ツールのサポートが発表されました。

Amazon RDS for PostgreSQLのアップデート- リードレプリカ、9.3.5のサポート、データ移行、3つの新しい拡張モジュール

　Londisteというツールでレプリケーションを組むことで、マスターサーバからデータを送りつける感じ？でコピーを作成するようです。
　そして検証環境を組んでLondisteを使ってみようとしたのですが、上手く行かない。最新バージョンは3.xなのですが、PostgreSQL wikiには2.xの説明しかありません。3.xではコマンド体系が変わっているようで、なんとか付属のドキュメントを読みつつ試してみたのですが、全く動きそうなところにも持って行けませんでした。
　この時点でVPSでの運用ができなくなり、自宅サーバに戻って速度の出ないディスクを前に未処理のデータが溜まり続けるという前にも後ろにも進めないような状況に陥ってしまいました。
　「早く標準のストリーミングで移行できるようにしてくれ」と願っている時間もなく、RDSの仕組みを見る限り、ターミナルにログインしてpg_basebackupコマンドを叩けるような構成では無さそうです。
　仕方なく、オーソドックスなpg_dump、psqlの組み合わせで移行しました。


　データベース作成には、LC_COLLATE、LC_CTYPEの設定が必要だったため、既存のデータベースの削除と、テーブルスペース作成・データベースの作成までは先に済ませます。

CREATE DATABASE favlook
  WITH OWNER = favlook
       ENCODING = 'UTF8'
       TABLESPACE = hoge
       LC_COLLATE = 'C'
       LC_CTYPE = 'C'
       TEMPLATE = template0
       CONNECTION LIMIT = -1;

続いて元のサーバからデータのエクスポート
　RDSでは、rdsadminユーザーがSUPERUSER権限を持ち、サーバを建てた時点で作られているユーザーにはrds_superuserという権限が与えられています。
　こんな感じ

-- Role: rdsadmin
CREATE ROLE rdsadmin LOGIN
  SUPERUSER INHERIT CREATEDB CREATEROLE REPLICATION;

ALTER ROLE rdsadmin
  SET log_statement = 'none';
ALTER ROLE rdsadmin
  SET log_min_error_statement = 'panic';
ALTER ROLE rdsadmin
  SET log_min_messages = 'panic';
ALTER ROLE rdsadmin
  SET exit_on_error = '0';
ALTER ROLE rdsadmin
  SET TimeZone = 'utc';

-- Role: postgres
CREATE ROLE postgres LOGIN
  NOSUPERUSER INHERIT CREATEDB CREATEROLE NOREPLICATION;
GRANT rds_superuser TO postgres;

単純にpg_dumpでデータを出力すると、テーブルの権限を設定する部分で警告が出まくります。
　ですので、--no-ownerオプションをつけて、ログインユーザーで作成します。

pg_dump -U [user] -f table.sql --no-owner --no-tablespaces -s [database]

これでテーブルを作成し、あとは必要なデータからコピーしていくという流れで移行しました。

　本格的な運用はまだこれからですが、とりあえずtextsearch_jaを使っていた処理をどうしようかなぁ、というところです。サーバ側でカスタマイズは難しそうなので、postgresql_fdwみたいな感じで、postgresql_RPCとかできると良さそうですね。


明日はsoneさんの今、データベースは中国地方が一番アツい！！ です。