Speee DEVELOPER BLOG

Speee開発陣による技術情報発信ブログです。 メディア開発・運用、スマートフォンアプリ開発、Webマーケティング、アドテクなどで培った技術ノウハウを発信していきます!

DBを移動してインフラをシャープにした話

※この記事は、Speee Advent Calendar8日目の記事です。 昨日の記事はこちら

tech.speee.jp


こんにちは!22卒エンジニアで現在DX事業本部開発基盤チームでSREをしている角です。この記事ではイエウールとおうちの語り部のDBをAWSアカウント間で移動させて技術的負債を解消したことについて紹介します。


イエウールは、「デジタルで快適な売却体験を提供する」というビジョンを掲げ、一戸建てやマンション、土地など、あらゆる不動産売却を考えている方と、不動産会社をつなぐマッチングサービスです。

ieul.jp

今までのイエウールのインフラ

今までのイエウールとおうちの語り部のインフラ構成は以下のようなものでした。

この構成は依存関係の強いWebサーバーとDBが別々のAWSアカウントで管理されており非常に扱いづらいです。歴史的な経緯がありこのような構成になったので説明します。

イエウール

イエウールはDX事業本部で最も歴史が長く、最も大きなサービスです。全てを書くのは難しいため直近2年の出来事について取り上げます。

2年前のイエウールは1つのAWSアカウントに本番環境と検証環境が相乗りしている状態でした。これだと検証環境での誤操作によって本番にも影響が出かねません。そこで、2021年3月にインフラ基盤をKubernetesへ刷新した際に、本番環境と検証環境が別々のAWSアカウントへ分離されました。しかし、Kubernetes化の作業が大変でDBやElastiCacheなどのリソースの移動は後からやることになり、旧アカウントに残りました。

おうちの語り部

DX事業本部では開発が活発なサービスに関してはアジリティを上げるため、シングルテナント戦略を採用しています。

andpad.connpass.com

docs.google.com


おうちの語り部もシングルテナント戦略を採用してAWSアカウントを専用に用意することになりました。しかし、独立してサービスとしての開発アジリティを必要とするPhaseを超え、安定稼働のPhaseになりました。それゆえ、シングルテナントのメリットが減少して、インフラ管理コスト増大のデメリットの方が大きくなりました。そこで、イエウールとのインフラ基盤の統合を行うことになりました。

最初は順調に統合作業が進み、Kubernetesクラスタの共有やほとんどのAWSリソースのイエウールアカウントへの移動は完了しました。しかし、DBとElastiCacheについては旧アカウントに残りました。

DBのアカウント間移動

DBの移動は、保存されているデータを不整合なく移さなければいけません。これを実現する一番オーソドックスなやり方は、書き込みを止めてdump importによってデータを移すことでしょう。しかし、イエウールではdump importに1時間以上かかるため、その間ずっと書き込みを止めてしまうのは売上や顧客からの信用を大きく毀損してしまいます。そこで、今回は旧DBから新DBにレプリケーションを行い、blue-green的な切り替えを行うことで書き込み停止時間を数分にとどめました。

1. レプリケーション

Amazon Aurora MySQL を使用したシングルマスターレプリケーション - Amazon Aurora

このドキュメントに従って実施しました。この時点でのダウンタイムはバイナリログをonにしたときのDBの再起動のみです。フェイルオーバーを利用して30秒程度のダウンタイムが発生しました。

2. DBの接続先を環境変数で扱う

イエウールのDBに接続しているシステムは、エンドユーザー向けのシステムの他に、社内向け管理システム、クライアント様向けの管理システム、複数の定期実行バッチなどがあります。また、大部分のシステムはrubyで作られていますが、いくつかの定期実行バッチと社内向け管理システムの一部はjavaで作られています。

これらのいくつものシステムがそれぞれ別々の方法でDBの接続情報を保持していたので、短時間で全てのシステムの接続するDBを切り替えることができません。そこで、Kubernetesのsecretを使ってpodに環境変数として渡す方法に一元化しました。これにより、secretの値を変えるだけで接続するDBを切り替えることができるようになりました。

3. 切り替え

切り替えの手順は以下です。

  1. レプリケーションマスター(旧DB)の書き込みを止める。
  2. レプリケーションマスター(旧DB)とレプリケーションスレーブ(新DB)のバイナリログを比較し、遅延がないことを確認。
  3. DBの接続設定を保存しているsecretを新DBに接続するよう書き換え。
  4. 全システムのpodを再起動する。

一連の作業にかかった時間は8分でした。

結果

こうなりました。

VPC peeringのようなアカウント間でやり取りするための設定を消すことができ、よりシンプルな構成になりました。また、おうちの語り部に関してはその後の作業で全てのリソースをイエウールアカウントに移しきることができ、アカウントを閉鎖することができました。

最後に

機能追加のようなシステムを大きくしていくことだと、目に見えた成果があるしエンジニアでない人からも喜ばれることも多いと思います。ですが、必要ない機能を削って今後の変更に耐えられるようにすることも、継続的に開発していくためには大切だと思っています。今後も、旧イエウールアカウントを閉鎖し終えるまで諦めずに走り切りたいと思います。


Speeeでは一緒にサービス開発を推進してくれる仲間を大募集しています!
こちらのFormよりカジュアル面談も気軽にお申し込みいただけます!

Speeeでは様々なポジションで募集中なので「どんなポジションがあるの?」と気になってくれてた方は、こちらチェックしてみてください!もちろんオープンポジション的に上記に限らず積極採用中です!!!