メールはツラいよ！！波乱のメールサーバAWS移行を振り返ってみる

はじめに
概要
- 移行したメール基盤について
- AWS移行における制約事項
設計
AWS移行前の準備
- AWS上でのプロビジョニング
- OSレイヤでのプロビジョニング
AWS移行中の課題
- 細かな設定値の調整とスケジュール
- AWS移行中に発生したトラブルの数々
AWS移行完了後の振り返り
- 普段からやっておいたほうが良いこと
- できればやっておいたほうが良いこと

はじめに

リブセンスインフラエンジニアのsheep_san_whiteです。お酒とロードバイクとランニングが好きなおじさんです。

リブセンスではオンプレミス環境からAWS環境への移行を進めてきました。移行対象がたくさんあったAWS移行が終わり、つい先日データセンタの解約も完了しました。今回は3年がかりの長期プロジェクトであったメール基盤の移行について振り返っていきます。

概要

移行したメール基盤について

社内に古来から商用ソフトウェアを使用したメール基盤があり、弊社の各種サービスのメール配信を支えてきました。

最初期に構築されたメールサーバは2013年製とかなり古く、設定をチューニングしたり途中から冗長構成化したり、長年継ぎ足されてきた秘伝のタレと化していました。

社内アクセスに制限しているためセキュリティ的には許容できるものの、以下の課題を抱えた状態からのスタートでした。

OSバージョンが古い
手動構築されたものなのでプロビジョニングが無い
(後から解ったのですが)最後にミドルウェアをチューニングしたのが2015年で、古い設定で動作していた

AWS移行における制約事項

オンプレミス環境からAWS環境への移行を進めるにあたり、以下の通りいくつかの制約事項がありました。

ライセンスの追加購入は不可
- ライセンスが高いので、移行時のライセンスの追加購入は諦めました
- (当たり前ですが)同時に複数のサーバで同一ライセンスを使用することはできないため、オンプレミス環境で動作していたサーバを止めて、AWS環境で環境でライセンスを流用したサーバを起動することが必要になります
IPレピュテーションの育成が必要
- メール配信においてはIPレピュテーションが非常に重要で、IPレピュテーションが低いと外部のメールサーバからスパム扱いされます
- オンプレミス環境のグローバルIPアドレスはAWS側へ移設できないため、IPレピュテーションはイチから育成が必要でした
- IPレピュテーションを育成するためには相当数のメールを複数のドメインに対して送信する必要があります
  - IPレピュテーションを育成できるほどのメールアドレスを用意することは困難であったため、少しずつ本番のメールを送りながらIPレピュテーションを育成する方針としました

上記の制約から以下の順序で移行を行う必要がありました。

オンプレミス環境で1台メールサーバを停止する
AWS環境で1台メールサーバを起動する
少しずつ本番環境のメールをAWS側へ流してIPレピュテーションを育成する
IPレピュテーションの育成が完了したら次のサーバ移行に進む

設計

機能要件の整理

オンプレミスに存在するサーバの機能要件をしっかり満たせるかを調査しました。

結構なメールの配信速度を求められるため、ディスクI/Oやスループットを特に意識して設計を進めました。

EC2インスタンスについては、オンプレミスのリソース使用実態に合わせつつ、1台につき ElasticIP を5つ追加するため m5.large を選択しました。

参考: Maximum IP addresses per network interface - Amazon Elastic Compute Cloud

移行過渡期の構成

移行時の制約事項から、いきなりAWS側へ切り替えることができないため、移行過渡期はハイブリッド構成を取る必要がありました。

オンプレミス環境では keepalived によるロードバランシング方式を取っていたため、EC2と通信させるためには DSR の対応を考慮する必要がありました。

そこで、EC2との間に HAProxy を噛ませて通信させることで DSR の問題を回避しました。

移行後の構成

IPレピュテーションの育成が完了した後はAWSで構成を完結できるため、 Internal NLB でロードバランシングする方式を取りました。

AWS移行前の準備

手動構築されたサーバであったため、プロビジョニングの整備を進めました。

AWS上でのプロビジョニング

AWSの管理はTerraformで行なっていますが、同一構成のサーバを複数台建てるためメールサーバ用にmoduleを作成しました。

OSレイヤでのプロビジョニング

ミドルウェアの動作環境の関係で、今まで採用実績のなかったAmazonLinux2を採用せざるを得ない状況であったため、Ansibleをスクラッチで書き始めました。

ECS化も検討はしましたが、 ElasticIP の取り回しなどを考慮して移行段階ではEC2にリフトするのみとしました。

AWS移行中の課題

細かな設定値の調整とスケジュール

IPレピュテーションを育成するために、ロードバランシングの重み付けを段階的に引き上げる必要があるため、以下の様な設定変更カレンダーを用意して徐々に重み付けを修正していきました。

同時にミドルウェアの配信速度も徐々に引き上げる必要があったため、送信するメールの通数・速度を増やしながらIPレピュテーションを育成しました。

IPレピュテーションの育成は1つのメールサーバあたり最低でも1ヶ月はかかる見込みでリードタイムが長いため、移行のスケジュールをしっかりと管理する必要がありました。

AWS移行中に発生したトラブルの数々

AWS移行時、様々なトラブルが発生したので概要だけ紹介します。

メールサーバの1台を移行中、オンプレミス側のメールサーバの1台でキューが溜まり続ける
- ディスクI/Oが悪いサーバが混じっていたせいで「メールのキューイング速度＞配信速度」となった
- 移行順序の入れ替えで解決した
icloud.com にブロックされる
- AWS移行したメールサーバから送っている特定ドメインのメールだけが icloud.com からブロックされた
- icloud.com のベストプラクティスに準拠することで解決した
  - ベストプラクティスとしては、SPF、DKIM の設定が必要だった
  - SPF はAWS移行前から設定していたが、DKIM を設定することで解決した
    - 他のメールサービスへの配信到達性を高めるため、併せて DMARC も設定した
社内で利用しているメールサーバ全てが Spamhaus のブロックリストに載ってしまう
- AWS移行したメールサーバから Outlook 向けの送信速度を上げた事が原因で何故か社内のメールサーバ全てが Spamhaus のブロックリストに掲載された
- 配信速度を切り戻し、Outlook 向けの配信速度は控えめにすることで解決した
一部サービスのメール配信基盤をAWS側のメールサーバへ向けるとタイムアウトが多発する
- AWS移行したメールサーバとメール基盤間を中継するためのメールサーバがキューイングシステムの役割を担っていたが、新規構成では不要と判断したことがそもそも間違いだった
- 中継用のメールサーバを「2024年令和最新」のメールサーバとして作り直し、解決した