技術的負債だらけのDjangoをAWSのコンテナで動かすまでの取り組み

弊社のメインサービスの負債が溜まりすぎていて、採用活動でPython2を使っているというのに罪悪感を感じていたのでバージョンアップした。

取り組む前の構成

やったこと

• Django1.4→1.11
• Python2の撲滅
• E2Eの自動化
• Nginx、Djangoのコンテナ化
• オンプレミスからAWSへの移行

Django1.4→1.11

テストコードがなければ無理だった。所要期間1ヶ月ちょっと。

1. Django1.4からDjango1.6へのアップデート
2. すべてのテストコードのオールグリーン化
3. Django1.6からDjango1.8へのアップデート
4. すべてのテストコードのオールグリーン化
5. Django1.8からDjango1.11へのアップデート
6. すべてのテストコードのオールグリーン化

ひたすら公式サイトのリリースノートを見てgrep、リリースノートを見てgrepの繰り返し。自社で使用しているRDBがSQLServerだったのでODBCドライバにも苦しめられた。DjangoとSQLServerはアンチパターンだと思う。

Python2の撲滅

文字コードの問題が多々起こった。所要期間2週間。

1. Python2.7からPython3.7へのアップデート
2. すべてのテストコードのオールグリーン化

Python2がなくなった！

Pythonの構文よりは依存しているライブラリ（標準、サードパーティ共に）の置き換えに苦労した。urllib2からrequestsへの書き換えが地味に数が多くて辛かった。後は例外と除算と剰余処理に気をつければなんとか。

E2Eの自動化

puppeteerはすごく楽で良い。所要期間1日。

1. puppeteerでの画面キャプチャ
2. OpenCVによる画像類似度で回帰テスト構築

JavaScriptの書き方に苦労した。スクレイピングはasync-waitの学習に最適。

Nginx、Djangoのコンテナ化

Dockerfileに苦しめられた。所要期間1週間。

1. Djangoのコンテナ化（プロセスはsupervisord）
2. Nginxのコンテナ化

Ansibleからの移行。Dockerの知識不足で現在イメージサイズは500MBオーバー...。軽くしないと。BuildKitやマルチステージを学べたのが良かった。docker-composeがbuildkitに対応しておらず(2019年10月11日現在)、ローカル環境向けのビルドで悩んでいる。

オンプレミスからAWSへの移行

AWSってなにそれおいしいの？所要期間2日。

1. ECS、ECRの導入
2. CodeBuildの導入

Jenkinsがなくなった！！
ECR初めて使ったんだけどめっちゃ楽だよこれなにこれ。

取り組んだ後の構成

所感

負債は早く払わないと、どんどん溜まる上に改修不可能になる。

同僚が「Python2じゃなくてPython3使いたい」って言った時「Python3使いたい、そんな言葉は使う必要がねえんだ。なぜならオレやオレの同僚はその言葉を頭に思い浮かべたときには！実際にPython3に上げちまってもうすでに終わっちまってるからだ！」って返事してた。

ただ、このバージョンアップの作業の間も新規機能やバグ改修もひっきりなしに行われていて、わりと高度なマージ操作が絶えず行われていて大変だった。それと負債を払う時間の確保が一番の課題だった。

「許可を求めるな謝罪せよ」の精神で取り組んだけど、謝罪して許してもらえるのは「すべてやりきった時」のみなので中途半端にあきらめず一気にやってしまうのがいいね。こんなことにモチベーションは何ヶ月も続かないし。