はじめに
こんにちは。2021年新卒の尾沼です。
私の所属する開発1部AXISグループの主業務の1つとして、弊社の在庫・販売管理システム「AXIS」の保守運用業務があります。その業務の一環として2022年の年始に本番DBのアップグレードを実施しました。今回はその振り返りをしたいと思います。
DBアップグレードの背景
AXISではRDBMSとしてPostgreSQLを利用しています。そして本番環境や検証環境ではAWSのAmazon Aurora PostgreSQL 互換エディションを利用してシステムを構築しています。 AXISではかねてよりAurora PostgreSQL バージョン 9.6 (PostgreSQL9.6と互換性がある)を利用していましたが、2021年の2月頃に以下のような通告がありました。
つまり、AXISで利用しているAurora PostgreSQL バージョン 9.6 は2022年末でサポートが切れ、強制的にバージョン10系以上にアップグレードされてしまうということです。
2021年、AXISでは100万件近い新規在庫が登録されました。もちろん昨年以前の累積の在庫データや在庫に関わるその他多くのデータをAXISは保持しています。2022年に入ってからも毎日数万件ずつ新たな在庫はAXISに登録され、バイセルの様々な部署でデータは利用されています。もし強制的にアップグレードが実施され、アップグレードに失敗しAXISのDBが止まってしまったらバイセルの業務に甚大な悪影響を及ぼすこととなります。そうした自体だけは何としてでも避ける必要があるため、強制アップグレードが行われる前に本番環境と検証環境のDBのアップグレードをする次第となりました。
DBアップグレードの流れ
細かい箇所は割愛しますが、全体の作業は以下のようなタイムラインで実施しました。他部署業務との調整もしつつのスケジュールなので、振り返ってみるとかなり長期に渡る業務だったのだなと思います。
| タイムライン | 実施内容 |
|---|---|
| 10月26日 | 検証環境のAurora PostgreSQLを10系にアップグレード(失敗) |
| 10月29日 | 検証環境のAurora PostgreSQLに対し、View定義修正SQLを流す |
| 〜11月7日 | 検証環境のAurora PostgreSQLアップグレード後に行うAXIS全フローのシナリオテストケース作成 |
| 11月8日 | 検証環境のAurora PostgreSQLを10系にアップグレード(再挑戦) |
| 11月9日 | 検証環境でシナリオテスト実行 |
| 12月7日 | 本番環境のAurora PostgreSQLをCloneを作成 |
| 12月10日 | 本番環境のAurora PostgreSQLのCloneにView定義修正SQLを流し、10系にアップグレード |
| 12月13日 | 本番環境のAurora PostgreSQLに対し、View定義修正SQLを流す |
| 1月5日 | 本番環境のAurora PostgreSQLを10系にアップグレード |
具体的なDBアップグレード作業は以下のように実施しました。
| ID | 内容 |
|---|---|
| 1 | 監視系ツールを止める（アップグレードの最中にダウンタイムが発生するため） |
| 2 | DBインスタンスのスナップショットを手動作成する |
| 3 | AWSマネジメントコンソールで手動でAurora PostgreSQLのバージョンを10系にアップグレード |
| 4 | Terraformのコード内容をAWSマネジメントコンソールに合わせてapplyする |
| 5 | 監視系ツールを再開する |
基本的にはTerraformで管理しているリソースはAWSマネジメントコンソールで更新すべきではありませんが、Terraformの処理順によるエラーを回避するために以下記事を参考にAWSマネジメントコンソールでアップグレード → Terraformを合わせる という順番で実施しました。
https://kennys.tech/terraform-aurora-upgrade/kennys.tech
アップグレード作業自体はそれほどボリュームのあるものではありませんでしたが、調査やドキュメント作成などを含めると実施に至るまでの作業量は多かった印象です。
振り返りポイント
検証環境のバージョンアップグレードに失敗
検証環境のAurora PostgreSQLのアップグレードには一度失敗しました。もし放っておいてAWSの強制DBアップグレードに任せていたらDBが止まる、または何かしら不具合が出る可能性が高かったと考えると恐ろしいです。。 アップグレード失敗の原因は2つありました。
Unknown型は10系ではサポートしない
検証環境のAurora PostgreSQLをアップグレードすると以下のメッセージが吐き出されました。
Your installation contains the "unknown" data type in user tables. This data type is no longer allowed in tables, so this cluster cannot currently be upgraded. You can remove the problem tables and restart the upgrade.
unknown型がテーブルに含まれているが、サポートされていないとのことです。公式ドキュメントにも確かにその旨は書いてありました。
そしてAWSは以下コマンドを用いてunknown型になっているカラムを特定せよと言ってきました。
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
しかし上記コマンドを打っても何もヒットしませんでした。原因調査のためにUbuntuコンテナを立てて、その中にAXISをローカル環境構築し、pg_upgradeコマンドを用いて10系にアップグレードしてみることで吐き出されるエラーと原因を調査しました。
すると、'#### hogehoge ####' AS hoges, のようにcastされていないカラムをデータ分析で利用しているViewやMaterialized Viewの中に見つけることができたので、castの対応('#### hogehoge ####'::text AS hoges, )を実施し、本エラーを解消することができました。
ViewやMaterialized Viewへ注意が向いていなかったことは反省です。
CASE節の中でset-return functionsを利用していた
以下のようなエラーがでました。
ERROR: set-returning functions are not allowed in CASE
これはUnknown型の原因調査時に発覚したことでした。ViewとMaterialized Viewの定義の中で9系から10系にアップグレードすると利用できなくなる書き方がありました。
こちらはCASE節の中でset-return functionsを利用しない方法で再定義することでエラーを解消することができました。 結果としてはエラーの存在の把握ができたから良かったものの、本来なら検証環境でアップグレードする前にローカルになるべくAWS上と似せた環境を用意して、上手く9系から10系にアップグレードできるかを検証するべきだったと思います。
Cloneでの検証
先述したように、検証環境でアップグレードする前にローカルになるべくAWS上と似せた環境を用意して、上手く9系から10系にアップグレードできるかを検証するべきだったと思います。それに加えて本番環境のデータで本番環境と同じ状態のAurora Clusterでアップグレードの練習ができるならばそれをやるに越したことはありません。 実際調査してみるとAWSにはClusterのCloneを作成する機能がありました。 dev.classmethod.jp
Cloneのメリットはアップグレードの練習ができるということだけではありませんでした。CloneはClone作成時の本番環境の状態を持つので、「万が一」本番DBが落ちてAXISからアクセスできなくなったとしても、AXISの向き先をCloneにしてあげることで応急的にAXISの機能維持ができるというメリットがあります。当初バックアップデータはpg_dumpコマンドでSQLファイルのdumpを取るで行く想定だったため、バックアップの手法が追加で1つ増えたのは安心に繋がりました。
終えてみての感想
私にとって本番環境と検証環境のDBのアップグレードは入社以来最も影響範囲が広く、また失敗した際のリスクも最も大きかったです。裁量と責任は表裏一体であることを意識する場面がいつにも増して多かったと思います。
もし失敗してデータが消えたら...。復元できるできないに関わらず、少しでも障害や他部署の業務を止めてしまうとその間の機会損失は何十万、何百万、はたまたそれ以上になります。そのため、徹底的に「万が一」を考えました。
しかし、上司や他AXISグループのチームメンバーからのフィードバックを通じて自分が「万が一」を考えきれていないことや、安直な考えになっていることを何度も痛感しました。
自分の頭と性格だけでは視点に偏りと不要なポジティブさが生まれてしまうことに気づけたので、今後仕事を進める上ではチームメンバーと意見交換する機会を意識的に増やしていこうと思います。
最後に、Buysell Technologiesではエンジニアを募集しています。興味がある方はぜひご応募ください！
