こんにちは。転職ドラフトでエンジニアをしている @verdy_266 です。
今回は、AWS 初心者である僕がとある計算処理の実行基盤を移行したことについてお話しします。
背景
転職ドラフトには、平均して2日に1回程度実行され、データを洗い替える役割を担っている秘伝の SQL があります。これを実行する一連の処理がなかなかのクセモノで、実行すると本番 RDS のリソースを食ってしまい、実行に失敗して障害対応に追われることがしばしばある状況でした。
しかし秘伝の SQL のメンテナンス自体はとても工数がかかることがわかったので、一旦 SQL のメンテナンスは先送りにし、 SQL を実行する基盤だけを本番環境から分離することになりました。サービス自体にできるだけ影響を与えない形で、別の場所で既存の計算処理を実行する形です。
ちょうど AWS について学びたいと言っていたタイミングだったので、僕がこの移行作業を担当することになりました。
AWS のお勉強をしてシステム構成図を作った
転職ドラフトでは AWS を使っていますが、僕自身 AWS 初心者だったので色々勉強しました。特に AWS JumpStart は AWS の主要サービスについて基礎から詳しく説明してくださり、とても勉強になりました。 参加前の僕は、ECS って EC2 のすごいやつなんでしょ？とか思っていたのはここだけの話です。
AWS JumpStart に参加したことで、システム構成図が作れるようになりました。今回のシステムは一般的な Web サービスとは異なるので勝手が違う部分もありますが、各サービスが何を担うのかを把握できれば構成図の作成自体はそこまで難しいものではなかったように思います。
マイルストーンを作った
システム構成図ができたのはいいのですが、何から作業に手をつけていいかわからず、手が止まる日々が続いてしまいました。そこで、どのような順番で構成していったら進んでいけそうかを考え、マイルストーンを作りました。
以下、マイルストーンごとにやったことを解説していくのですが、マイルストーン作成にあたって意識したことを先にご紹介しておきます。以下の3点です。
- コアの機能を実現できる最小の構成を作るところから始め、徐々に機能を足していく
- 1つのマイルストーンは、1週間程度で余裕を持って達成できる程度のものにする
- 触ったことがなくて想像もつかないマイルストーンは2週間確保しておいて、試しに触ってみる期間を確保する
振り返ると、1. が結構ミソだったなあと思っています。マイルストーンを作らずがむしゃらに進めようとしていた段階では、システム構成図の (1) から順番に実現しようと考えており、最初から ECS を構築する必要が出てきてしまいました。すると、最初のフェーズから新規に勉強することが多く、自分の処理限界を超えてしまうことが多々発生していました。これを、コアの機能が実行できるようにすることを最優先にして、いわばシステムの内側から外側に向けて構築していこうとすることで、マイルストーン同士の結びつきがスムーズになったように感じています。
システム構築の流れ
まずは EC2 内で計算処理を実行する
先述の通り ECS の扱いに慣れていなかったので、とりあえず EC2 で計算処理を実行してみるところから始めました。EC2 の中に Rails サーバーと MySQL を起動し、計算処理を実行してリソース使用率を計測し、RDS はどのくらいのインスタンスタイプを選択すれば良いかなどの当たりをつけました。
ECS と RDS を立ち上げ、計算処理を実行できるようにする
既存のプロダクションコードを参考にしつつ、ECS と RDS を構築します。この状態で計算処理を実行し、リソース使用率を計測して問題がないことを確かめます。
サービス本体の RDS と新規に作成した ECS を接続し、計算結果をサービス本体の RDS に INSERT できるようにする
セキュリティグループについて勉強してアクセス制限を適切に設定し、 mysqldump で計算結果を移すスクリプトを書きました。
実行結果の dump ファイルを S3 にバックアップできるようにする
mysqldump コマンドでデータを吸い取り、 mysql コマンドで挿入するというフローなので、 dump ファイルを S3 にアップロードすればそのままバックアップになります。
本体の RDS からデータを取ってきて、計算処理を実行して本体の RDS にデータを戻し、 dump ファイルは S3 にバックアップすることができれば、基本的な処理は完成です。
EventBridge を使って一連の処理を定期実行する
既存のデプロイフローを参考にしつつ、EventBridge にルールを設定できるようにしました。一連の処理はシェルスクリプトで定義しており、 EventBridge ルールからそのシェルスクリプトを実行する ECS タスクを起動する形としています。
Terraform でリソースを定義する
今まで AWS コンソールで作成していたリソースを、 Terraform で定義していきます。 Terraform も触ったことがなかったのでイチから勉強しましたが、既存のコードを参考にすることで実装自体はそこまで苦労しませんでした。
動作確認
計算処理の実行基盤を分離しているので、既存の計算処理の実行には影響を及ぼさない形での動作確認が可能です。同じ処理を実行している既存の処理を消さずに、別の時間帯に新しい計算処理を実行することで、万が一新しい計算処理が失敗したとしても、データとしては本番影響がないようにすることができました。
既存の計算処理を削除
既存の計算処理を削除することで、本番 RDS への負担が軽くなり、当初の目的を達成することができます。これについては今後実施予定です。
終わりに
AWS についてほぼ何もわからない状態から始め、Terraform などの周辺技術についてもカバーしつつ通り一遍のシステムを構築するということで、構想段階から合わせるとほぼ1年がかりのプロジェクトとなりました。一通り実装を経験すると、 AWS や Terraform に関する怖さがなくなり、開発関連の様々な話題について行けるようになったことや、マイルストーンを立てたことが一つのターニングポイントとなり、その後の作業が一気に進んだのが印象的でした。
今回のプロジェクトによって、転職ドラフトのサービスはより安定したものになったと思います。今後の転職ドラフトにもご期待ください。
