読者です 読者をやめる 読者になる 読者になる

すてにゃん氏の技術ぶろぐ

技術っぽいこと書きます

稼働中のサービスのテーブル構造変更とデータ移行

データベース

同僚のこういう記事を読み、そういえば自分もWeb系の企業に入ってから初めてデータ移行の流れとかを知ったなーとなったのと、せっかく技術ブログあるのにあまり書いてないのは勿体無いなーという気持ちからこの記事書いてみます。
www.yasuhisay.info

技術系の記事はもっと気楽に書いていきたいマン。

何がしたいのか

何らかの理由でデータベースの構造を変えたいとなった際、いきなりガバッと変えたいのもやまやまですが、動き続けているWebサービスだとそれはちょっとできないですよね。いきなり画面がみれなくなった!いきなりログインできなくなった!とかなると大変です。また、いじっている間に何かしらのミスでデータが飛んじゃって前の状態に戻せなくなるとか。Webサービスは出してから後々のリリースで修正を入れることは確かにできますがそれがデータベース層での変更でユーザが24時間使ってるようなサービスだとそうそう簡単に変更はできません。

我々が変えたい先のテーブルやカラムを新たに作り、そこに該当するデータを移行し、最終的にそちらを使うようにするとサービスを止める必要はないし、もしものときは前のテーブルの状態に戻せるので安心です。

流れ

  • 新しいテーブルを作る
  • 古いテーブルと新しいテーブル両方から読む(新しい方にデータあればそちらを優先)
  • データの作成や更新を古いテーブルだけでなく、新しいテーブルでもする
  • 古いテーブルにしかないデータを新しいテーブルのほうにもコピーする
  • 古いテーブルのほうから読み書きしないようにする
  • 古いテーブルの使わなくなったカラムなどはいらなければ落とす

どういうことか

自分は元々DBとか触ったことなかったのでなぜこんなに手順が多くてめんどうなのかと最初思いました。ただ、先ほども書いたように、ユーザは我々が開発したりデプロイしたりしている間もサービスを触っているかもしれないし、途中の段階でおかしくなると困ります。そこで一時的に二つのテーブルから読み書きするようにして最終的に新しいほうを使う、とすると安心という感じですね。

ほか

こういったことを自分が以前した際はペアプロしつつやったのですが、マイグレーションの下準備としてまずはテストケースをもっと増やしたり、ファイルの分割をしたりしました。これらはマイグレーションというよりリファクタリングですが、安心してデータベースマイグレーションを実行するのに大事でした。上の流れのようにまとめると結構簡単そうですが、実際にはその古いDBのカラムをいろいろなところで実は参照しているとか色々なタイミングで更新してる可能性があるので、それらのテストケースが豊富のほうが自信を持って実行できるんだなぁと改めてテストのありがたさを感じました。

チームに新しいメンバーが加わったときに気をつけてる事

開発 考え事

現在はてなのMackerelチームにてアプリケーションエンジニアをやっている id:stefafafan です。先日私のチームに id:Soudai さんがジョインしました。まだまだ入社して間もないのですがチームメンバーだけでなく、会社の色んな方と打ち解けているのを感じててすごいなと思っています。彼のこの記事を読んでとても良いなと感じたので、私は逆に新卒2年目の目線で自分が気をつけてる事を書いていこうと思います。
soudai.hatenablog.com

続きを読む

AWS初心者がEC2, RDS, ALB, NAT Gatewayを使ったときに直面した様々な概念

Advent Calendar AWS mackerel

こちらははてなエンジニアアドベントカレンダー 2016の11日目の記事です。
developer.hatenastaff.com

前日は id:Windymelt さんの「趣味のプログラミングから職業としてのプログラミングへ」でした。
windymelt.hatenablog.com

今回はAWSサービスをいくつか触ってみた話について書きたいと思います。

続きを読む