PR TIMESシステムのクラウドジャーニーのもう一ステップ、PR TIMES TVサービスのAWS移行の話

2023年10月12日

Dung Bui Ke

URLをコピーしました！

こんにちは、PR TIMESのバックエンドエンジニアのズンです。今回は担当していたPR TIMES TVサービスのAWS移行について話したいと思います。

前回のPR TIMESのAWS移行の話の記事もありますので、ぜひご覧ください。

PR TIMES 開発者ブログ

PR TIMESをオンプレミスからAWSに移行しましたこんにちは、開発本部インフラチームテックリードの櫻井です。今回は2022年9月に行ったオンプレミスからAWS…

PR TIMES TVとは

PR TIMES TVは、PR TIMESが提供する動画PRサービスであり、ニュース動画やドキュメンタリー動画、ライブ配信を手掛けています。

データセンターを撤退するためには、PR TIMES TVの移行が不可欠でした。PR TIMES TVは、データベースやロードバランサーなどを過去のオンプレミスのPR TIMESプレスリリース配信サービスに依存するインフラ構築になっていた状況で、AWS移行を実行しました。

移行戦略

PR TIMES TVサービスのオンプレミス環境は以下のメイン要素があります。

Ruby on Railsウェブアプリケーションを運営していたウェブサーバー３台
メディアファイルを保存するためのNFSを自前で構築していたストレージサーバー
PostgreSQLで過去のオンプレミスのPR TIMESプレスリリース配信サービスと同居していたデータベース

元のオンプレミス環境でPR TIMES TVサービスもPR TIMESプレスリリース配信サービスと同じネットワークで設定していました。しかし、AWSへの移行に際して、PR TIMES TVサービスは管理しやすくするために別のVPCに配置することを決定しました。

移行時の環境の差を小さくするために、ウェブサーバーとデプロイサーバーにはAmazon EC2を採用しました。また、オンプレミスで使用されていたデータベースがPostgreSQLだったため、AWSへの移行時にはAmazon RDS for PostgreSQLを使用することを決めました。

PR TIMES TVサービスは動画配信サービスなので、データベースより、ファイルサーバーの容量が大きいです。ファイルストレージといえば、Amazon S3は理想的なサービスですが、現時点ではNFSに基づいたストレージサーバーを利用していたため、S3を使えばアプリケーションのロジックを大きい範囲で修正する必要があります。アプリケーションコードをできる限り変更せずに移行できるかつ、信頼性が高い解決法として、Amazon Elastic File System（EFS）サービスを使うことに決めました。

また、ロードバランサーがオンプレミスで過去のPR TIMESプレスリリース配信サービスと同じものを流用していたこともあり、移行対象となりました。

まとめで、移行対象と使用するAWSのサービスは以下のようになります：

Webサーバー、デプロイサーバー ⇒ Amazon EC2
データベース ⇒ Amazon RDS for PostgreSQL
ファイルストレージ ⇒ Amazon Elastic File System（EFS）
ロードバランサー ⇒ AWS Elastic LoadBalancerのApplication LoadBalancer

ネットワークの構築

最初に、Amazon Virtual Private Cloud（Amazon VPC）を構築しました。

昔のオンプレミス環境構築では、PR TIMES TVサービスとPR TIMESプレスリリース配信サービスが同じネットワークで構成され、/tvへのリクエストはプレスリリース配信サービスのサーバーでProxy処理されました。しかし、今回の移行でAWSでVPCを分割するためにはVPC Peeringの設定が必要でした。VPCを作成する際には、CIDR Blockが衝突しないように注意し、VPCを作成しました。
セキュリティ上の理由から、Public SubnetとPrivate Subnetに分割しました。さらに、Application Load Balancerを作成する際には、最低でも2つのAvailability Zoneを指定する必要があるため、計4つのSubnetを作成しました（public1a、public1c、private1a、private1c）。しかし、工数を考慮して、AZ ap-northeastｰ1aしか利用しませんでした。
プライベートサブネット内のウェブサーバーがインターネットにアクセスできるように、Public Subnetのpublic1aにNAT Gatewayを作成しました。
Public Subnetのpublic1aとpublic1cを指定して、Application Load Balancerを作成しました。
PR TIMESプレスリリース配信サービスのVPCにVPC Peeringを設定しました。
仕様に合わせて、Route TableとSecurity Groupsも設定しました。
データのオンプレミスからの移行を考慮して、新しいPR TIMES TV VPCと既存のオンプレミス環境内にDirect Connectも設定しました。

AWS環境の構築を管理しやすいために、Terraformを使用し、Infrastructure as Code（IaC）を活用しています。

また、ネットワークの構築とデバッグにはReachability Analyzerというツールを活用しました。

Reachability AnalyzerはAWS上のネットワーク内で、送信先と受信先を指定してアクセスできるかどうかを確認するツールです。もしアクセスできない場合、通信がブロックされた側を教えてくれるため、修正が迅速に行えます。非常に便利なツールです。

ウェブサーバーの構築

移行戦略に従って、Amazon EC2を使用してウェブサーバーを構築しました。

既存のオンプレミス環境の状況を参考に、各サーバーにはEC2の「c6i.large」インスタンスとAmazon EBS 100GBを使用しました。デプロイサーバーにはt3.smallインスタンスを使用しました。

先日この開発者ブログでも紹介した内容を参考に、サーバーへの接続にAWS Session Managerを使用するようにしました。

PR TIMES 開発者ブログ

AWS Session Managerを使ってプライベートサブネット内のEC2インスタンスに接続するこんにちは、開発本部インフラチームテックリードの櫻井です。今回は先日導入したAWS Session Mana…

PR TIMESではサーバーのConfigurationがAnsibleで管理されています。そのおかげで、Ansibleでサーバーの設定を反映して、ソースコードをデプロイして、早くアプリケーションをビルドできました。

ファイルサーバー構築

ファイルサーバーのためにAmazon Elastic File System (Amazon EFS)を選択しました。

Amazon EFSは、サーバーレスで完全にスケーラブルなファイルストレージを提供するサービスです。アプリケーションの中断なしに、ファイルの追加や削除に伴って自動的にスケーリングし、オンデマンドで拡張することができます。また、Amazon EFSはネットワークファイルシステムバージョン4（NFSv4.1およびNFSv4.0）プロトコルをサポートしており、既存のオンプレミスのファイルサーバーの代替に適しています。そのため、Amazon EFSを利用することにしました。

Amazon EFSはFull-Managedサービスなので、ストレージの名前とVPCを指定すると、簡単にEFS ストレージを作成できます。

EFSストレージにアクセスするためには、マウントターゲット（Mount Targets）を作成する必要があります。マウントターゲットは独自のIPアドレスを持ち、EFSストレージへのゲートのような役割を果たします。各Availability Zoneには、マウントターゲットを1つしか作成できない制限があります。

LinuxサーバーのEC2インスタンスでEFSファイルシステムをマウントするためには、**EFS マウントヘルパー**をインストールしておく必要があります。

NFSを使用してEC2インスタンスを再起動しても、EFSファイルシステムを自動的にマウントすることができます。Linuxインスタンスでは、/etc/fstabファイルに以下の設定を追加することで実現できます。

{{ efs.mount_target_ip }}:/ {{ efs.mount_dir }} nfs4 nfsvers=4.1 0 0

EFSファイルシステムがマウントされた後、オンプレミスファイルストレージサーバーからEFSへのファイル転送を検討しました。転送するファイルの容量は500GBを超えていました。AWSはファイル転送サービスを提供していますが、ファイル容量が500GBだったのはあまり多くないと言えるので、rsyncを用いて簡単にコピーできるので、rsyncを利用してファイルをコピーすることに決めました。そのため、AWS上で新作したVPCでワーカーサーバーを構築し、オンプレミスファイルストレージ（設定したDirect Connect経由）とEFSファイルストレージの両方をマウントし、Rsyncを使用してファイルのコピーを実装しました。

rsync -a --verbose {オンプレミスファイルストレージ} {EFSファイルストレージ}

ファイルサーバーのデータマイグレーションは5時間で完了しました。次回rsyncを実装する際には、「新しいファイルだけをコピーする」ために--updateオプションを指定し、「削除されたファイルがコピー先でも削除される」ために--deleteオプションを指定することをおすすめします。

データベース作成

以前に話した移行戦略により、Amazon RDS for PostgreSQLを採用しました。データベースの移行と同時に、PostgreSQL 14.6へのアップグレードも実施しました。そのため、ウェブサーバーにはpostgresql-14系のパッケージをインストールする必要がありました。

PR TIMES TVサービスのファイルストレージは大容量ですが、逆にデータベースの容量は小さかったです。pg_dumpとpg_restoreを利用することで、簡単にデータベースの移行を行うことができました。

モニタリング設定

AWS環境でWebサービスが正常に稼働していることを確認した後、モニタリングも設定しました。

アプリケーションの監視にはNew Relicを利用し、AWSリソースの監視にはMackerelとAmazon CloudWatchを利用しています。

移行した際に発生した問題

いくつか発生した問題と学びになったことを紹介いたします。

PR TIMES TVへのリクエストの一部が504 Timeoutエラーが出た

システムは上記の要件に基づいて構築されましたが、1つの問題が発生しました。システムを移行した後、PR TIMES TVへのリクエストの一部が504 Timeoutエラーになりました。このTimeoutエラーの原因は、最初に作成したALBがPublic Subnetのpublic1aとpublic1cに配置されていたが、Availability Zone 1cは使用しないと考えていたため、Route TableにはRouteが追加されていなかったことです。その結果、Public Subnetのpublic1cにあるALBからウェブサーバーが設定されているPrivate Subnetのprivate1aに通信できませんでした。

例えばTV STGのALBを見ると、ALBが1台だけ表示されています。

しかし、nslookupコマンドを使ってDNS名を調べてみれば、IPアドレスが２個見えて、背後にはALBが2台存在していることが理解できます。

PostgreSQL 14のパッケージの非互換問題

サーバーのオペレーティングシステムはCentOSを利用しているので、PostgreSQL 14.6にアップグレードする際には、postgresql-14系のパッケージをインストールする必要がありました。しかし、PostgreSQLに関する情報を提供するツールであるpg_configのPATHが変更され、それによりRuby on Railsで作成したアプリケーションのビルドが実行できない問題が発生しました。

この問題を解決するために、Capistranoのデプロイスクリプトに.bundle/configにオプションを指定するタスクを追加しました。

# Set bundle config before bundle install
namespace :bundler do
  before :install, :prepare_bundle do
    on roles(:web) do
      within release_path do
        execute :bundle, 'config --local build.pg --with-pg-config=/usr/pgsql-14/bin/pg_config'
      end
    end
  end
end