オミカレでテックリードをしております、高橋です。 ちなみにその任も後2週間足らずで終わりです。 3月からは別の会社で働く事になっておりますが、これは転職 or 退職エントリでは無いのでまたの機会に..!
いやぁーーー、この2〜3ヶ月、本当に色んなタスクを倒してきたなーーー！
— ikkitang (@ikkitang) 2021年2月11日
DMS撤退に始まり数十万円単位でのインフラリソースの削減等も完了出来る状態になった。思い残す事は何も無い。
という事で本日、高橋は最終出社日でございます！
さて、表題の通りですが、この度 オミカレでの最後の大仕事として DMS撤退、Aurora撤退を決めてきたので どんな風に進めてきたか、みたいなのをアウトプットしようかと思います。
意思決定プロセスみたいなのも僕の能力で実現出来る限り言語化してみようと思うのでなにかご参考になれば嬉しいな、と思う限りです。
ちなみに、書いてみるとDMS撤退だけでそこそこのボリュームになったので Aurora撤退編とDMS撤退編とで分割しようと思います。
後編はこちらです。
前提の記述
フィードバックを頂きましたので明示しておきまーーす。
※ この記事内では、 Aurora と記述がある場合は 明示がない限りは Amazon Aurora MySQL v1.x として扱う事とします。
※ この記事では 移行先の文脈で言及している際の PostgreSQLは RDS PostgreSQL の事を指してます。 Amazon Aurora PostgreSQL ではありません。
オミカレとDMS
まず前提知識みたいなのを紹介したいと思います。 オミカレはDMSを少し特殊な使用方法で運用しています。詳細については以前 PostgreSQL カンファレンスにてお話させていただいた事があるので、そちらが参考になるかと思います。
他にも OSCの各地域やJAWS-UG 岡山 とかでもお話した記憶がありますね。
まあ、概要を説明するとこんな感じです。
- Aurora MySQLを使用したDBを諸々の理由からリファクタリングしてRDS PostgreSQLにするというプロジェクト
- DMSによって Aurora MySQL => RDS PostgreSQL にデータを異種間レプリケーション
- DMSがPostgreSQLへ書き込みを行った時にトリガーを発火させてリファクタリング後のテーブルに入れる
- データの書込/参照 はAPIにて行うように統一する
- APIを用いて PostgreSQL側のデータを参照するようにアプリケーションを変更していき、参照が全てPostgreSQL側に切り替わったら、書き込みをこれまたAPI経由でPostgreSQL側にのみ行うようにする
- 全てPostgreSQL側に切り替わったら、DMSのレプリケーション設定からそのテーブルを除外する
こんな感じです。 当時のCTOのそーだいさんが大体全部設計してくれて、自分が手を動かすみたいな感じでやっていました。
DMSで移行しているテーブルは Amazon で例えると 商品情報 ・ 出品者情報 ・ 購入履歴情報 ・ プロモコード情報 ・ PR商品情報 という感じでまあ、これによりサービスの根幹を担うテーブルが処理されている状態でした。
DMS撤退について
前述の通り、オミカレでの最後の大仕事です。 退職にあたって 「DMS撤退は最後までやりきる」 という感じで約束を取り付けたので、実質 去年の12月頭から今月の有給消化開始の3ヶ月間でなんとしてもやりきる という方針で進める覚悟を持って挑みました。
ただ、このスケジュール感では、当初の DMSによるDBリファクタリングプロジェクト を完遂させる事は出来ません。
という事で、「残ったメンバーに引き継ぎ出来る状態にする」 という所を軸に意思決定を行う事としました。 DMSを撤退させないといけない理由は色々あるのですが、大きな部分として 「DMSの運用知見が高橋にほぼ全て寄ってる」 / 「トリガーの運用知見が高橋に全て寄ってる」 という話が大きい部分でした。
チーム状況として10人に満たないスタートアップの開発メンバーという所もあり、並列分散よりも直列で突き抜ける方針になるというのは自分の周りでは良く聞く話ではあるのですが、とにかく引き継ぎするにもコストがかなり掛かる、という所はネックでした。
そこで DMSによるDBリファクタリングプロジェクト というプロジェクトを DMS撤退 と MySQL撤退(PostgreSQL切り替え) に分割した上で DMS撤退 を完全にやりきる覚悟を決めました。
どうすれば、DMSが撤退出来るのか
DMSは MySQLのデータの更新を検知してPostgreSQL側にリファクタリングして入れる という役割を担っています。 つまり、それが別の仕組みで実現できれば、DMSがやる仕事はなくなり撤退出来るという事になります。
大きな課題は 「MySQLのデータの更新を検知するにはどうするか」 で、この課題さえどうにかなれば、MySQLのデータからPostgreSQLのデータを生成するロジックは既にトリガーがあるのでそれを別言語に移植する程度で済みそうです。
DMSはポーリングで実現されたりしてはいます...が、今回はあくまで引き継ぎコストをへらす為のプロジェクト。今から新しい仕組みを作るのは本末転倒です。 出来る限りシンプルであり、かつ残ったメンバーの得意分野的にL7に近い解決方法を選択する事が求められます。
L7という事で、MySQLのデータの更新されるパターンを考えてみました。 現状でいうと、以下の図のように サービスA ~ D において、色んな箇所から MySQLのデータが更新されていて、それによって複雑度が増している、という状況でした。
- 更新はAPIからのみにする
- サービスA〜DはAPI経由でMySQLにデータを書き込む`
これが実現できれば、MySQLへの書込みはAPIのアプリケーション内で検知でき、残ったメンバーは コードを読む事で 仕様が把握出来そうです。（泥臭いが）
また、僕はAPIを書く（DjangoでAPIを設計・コーディングする）事が好きだし、こんなにビジネスロジックがぐちゃぐちゃの箇所をリファクタリングしてきれいなコードに出来る機会があるとか面白そうでしょうがないな、って思いもありました。 途中でモチベーションが下がるみたいなのも無さそうだな、というのも選定理由としてあります。
という事で上記方針で進める事としました。
サービスA〜D の各コードを grep して（震）、更新箇所のコードの内容やメソッドの意味を把握し（震）、 APIの実装 および サービスA〜Dの更新処理のAPI化 を実行しました。
結果的に上記にて、なんとかやり遂げる事が出来ました。
図と合わせる為にサービスA〜D と書いていますが、主に 更新を担っていたのは サービスA が 9割9分だったので、そこは一つの成功要因だと思います。
DMS撤退にあたって気をつけた事や学べた事・自画自賛ポイント
テックリードとしてプロジェクトに臨む所でいうと、残ったチームのメンバーの得意分野を考えながら技術選定をする、というのは至上命令でした。
プレイヤーとしては、DBリファクタリング / コードリファクタリング の経験値を非常に得られた良いプロジェクトだったな、と思います。
特に既存の古いコードを別言語（公開情報なので言っても大丈夫とおもってますが、既存コードはPHP で APIはPython ）でリファクタリングする経験値が得られたのは今後のいい経験になりそうだな、と思っています。 最近、リアーキテクトで言語を変えるとかよくある事例ですしね。
特筆して得られた知見として、別言語での実装方針として、既存の古いコードを持ってくる時に手を入れるのでは無く、なるべく既存コード側を予めリファクタリングしてリリースして動かす => 問題なさそうなら別言語へ移植 とやる事でプロジェクトの安定感は格段に増すな、っていうのが肌感でありました。
その他で上げるとするなら、思考停止で全部API化して持っていく、とするのではなくて 「これはいらんやろ」 的な処理は撤廃出来た事は エンジニアとして チームを横断的に渡り歩けた良い成功体験になったなと思っています。
削除の取消機能 とかね。。（震） 辛い記憶しか無かったので、機能を排除する相談の場とかを設けて消すとかをしました。
根幹のテーブルが沢山関わっているプロジェクトではありましたが、比較的僕が携わったプロジェクトの中では安定して進められたなと思っています。 致命傷的なのは無くて ボヤ（大小様々） は数えるほどしか無かったのが幸いです。
結果としてスケジュール遅延がそれほど無く進んだ、という観点でいうと DMSのレプリケーションタスク 単位でスケジュールを考える事が出来たからなのかな、というのが学びとしてあります。
DMSのレプリケーションタスク を親課題として 捉えて、 そのテーブルを更新しているサービスA〜D内のコードをAPIとして公開する と 更新箇所をAPI化する というのが子タスクでぶら下がるような感覚で非常に進めやすかったです。見積もりがブレにくい構造になってたのがあるな、という学びがありました。 運用知見から どれがタスクとしてでかいか が完全に把握出来てたみたいなのも大きな要因かもしれないですね。
このプロジェクトが始動してから、約2年半ぐらいです。 長かったけど、やっとどうにかする事が出来ました。 全体として、本当に大きな学びがあったプロジェクトだったな、と思います。
まとめ
改めて、DMS撤退がなんとかなってよかったと思います。
これは次編の 「Aurora撤退」 にも効いてきます。 DMSはAuroraと密接に結びついていたので、「Auroraに手を入れたいがDMSがある事によって手が出せない」というジレンマがずっとありました。
やっとAuroraに手を入れる事が出来る！ という事で 続編の執筆も開始したいと思います。
長文読んでくださりありがとうございました！！
