Help us understand the problem. What is going on with this article?

RDS(PostgreSQL)からAuroraに移行した話

はじめに

投稿者は普段RubyでWebアプリを作っています。
これまで業務でAWSを使ったことはありません。
今回たまたまAWSに触らせてもらえる機会を頂きました。
備忘のために、やったことをまとめておきます。

構成

変更前 変更後
Postgres9.6.1
MultiAZ + リードレプリカ
AuroraPostgreSQL 9.6.8
メイン + リーダー(非常時昇格)

その他環境周り

  • 言語: Ruby、Ruby on Rails
  • WEBサーバ: Apache (Passengerも使用)
  • その他: delayed_job(非同期処理用のgem)

移行に伴いやったこと

実行日、時間帯の検討

月半ばの月曜日、時間帯は早朝

<理由>


月半ばの月曜日

月末月初はバッチ処理が走るので避けました。

また、週末は休日を跨ぐため、何かあった時にその週で対応できるように月曜に決定。

早朝

サービスのトランザクション量を調査し、一番少なかった早朝をチョイス。

移行手順を考える

当日のメンテナンス時間を最小に抑えることを優先しました。
Auroraリードレプリカを前日に作成しておき、
当日メンテナンス中は昇格とDNS切り替えのみ行うような手順にしました。

実際の手順

  • 前日
    • Aurora用にSG、パラメータグループを作成
    • パラメータグループに関連付けしてAuroraリードレプリカ作成
    • イベントサブスクリプション作成、Auroraリードレプリカに適用
  • 当日
    • Auroraリードレプリカへの接続を確認
    • 既存RDSとAuroraリードレプリカのレプリケーション確認
    • 既存RDSのイベントサブスクリプション解除(作業中のアラート抑止)
    • AutoScaling設定を1に変更(EC2操作)
    • メンテナンスモードON
    • Apacheの停止
    • delayed_job停止
    • Auroraリードレプリカ昇格
    • DNS切り替え(Route53操作 CNAME変更)
    • DNS切り替え確認
    • 既存RDSと昇格後Auroraのレプリケーション確認
    • Auroraにシーケンス同期用パッチを実行
    • 既存RDSと昇格後Auroraのシーケンス同期確認
    • 旧RDSのSG変更(アクセス不可用のSGを割り当て。 誤接続防止)
    • Apache起動
    • delayed_job起動
    • メンテナンスモードOFF
    • AutoScalingを元に戻す

ポイント

  • メンテンスモードについて
    当日はmaintenance.htmlを所定の場所に配置/削除でON/OFF切り替え。
    以下を参考にさせて頂きました。
    Apache httpd でメンテナンスモード

  • AutoScaling設定

    • キャパシティを1にすることで作業対象を集約。作業時間の短縮ができました。
      (戻す手順も忘れずに!
  • Apache、passenger 停止/起動

    • 残プロセスがあるとrails(ActiveRecord)のコネクションプールにより、
      DNSを変えてもDBの向き先が切り替わりません。(はまった点。)
  • delayed_job 停止/起動

    • 非同期処理をしているので、実行中プロセスをリセット後に実施した方が安全と判断。
  • シーケンス同期用パッチ

作業時の気づき

  • PostgresRDSのバージョンが9.6以前のインスタンスは、
    アクションに「Auroraリードレプリカの作成」項目が表示されない。

    • まずはRDSをバージョンアップするか、スナップショット経由で
      移行する形式になりそうです。
  • Auroraパラメータグループにはクラスター用とDBインスタンス用があり、
    両方作成しておく必要がある。

  • Auroraクラスター配下にリーダー(読み込み用インスタンス)を作成すると、
    クラスターの読み込みエンドポイント経由で自動でリーダーにアクセスできる。

  • リードレプリカ昇格を待っている間にDNSの切り替えは可能であることがわかった。

    • 作業時間短縮に繋がりました。
  • インスタンス作成時に拡張モニタリング設定をONにする場合、
    RDSの全アクセス権限だけでは足りないので確認が必要。

    • CloudWatchかと思いましたが権限を追加してもらってもできず、
      結局パワーユーザーの人にお願いしました。
  • RDSのセキュリティーグループはすべて外すとデフォルトが適用される。

    • 誤接続防止はインバウンドに何も指定しないSGを作成して適用すればOK!
  • リードレプリカおよび昇格後のレプリケーションはきっちりされる。

    • 当たり前かもしれませんが、確認することでAWSの便利さを再認識しました。
  • Railsからアクセス中にフェイルオーバーさせると、
    切り替えを検知できずに書き込み処理でエラーが発生する。

    • RailsではPG::Connectionエラーとなるので対処が必要です。

まとめ

普段とは全然違う領域での作業で右も左もわからず、
色々な人を巻き込み(多大な迷惑をかけつつ)無事に移行できました。
協力頂いたみなさんには大変感謝しております。
今後もインフラ関連を勉強してエンジニアとしての視野を広げていきたいです。

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away