増分アップデート

incrementalupdate ファイルの更新が必要な状況で、変更されたものだけが含まれたパッチファイルをダウンロードし、ローカルで直接パッチする方法

概要

2021年、ITワクチン会社で産業技能要員(兵役制度)として働いていた当時「増分アップデート」というプロジェクトを一人で担当した。

会社ではAWS3から1MBファイルを顧客に毎回提供していたが、

このファイルは顧客にとって非常に重要なファイルで、内容が変更されるやいなや顧客は再びダウンロードしなければならなかった。

当時新入社員として多少萎縮していた私にものすごい成長と自信感を植え付けてくれたプロジェクトでもある。

この1MBファイルの内容変更は他の部署で行われた。

したがって、既存の仕事処理方式を最大限維持する方向で機能を検討した。

他の部署で1MBファイルを変更してアップロードする時、自動化triggerが作動し直前アップロードファイルと現ファイルのdiffでパッチファイルを作るようにした。
そして、このパッチファイルをサーバーに自動的に配布し、クライアントがアップデート時に該当ファイルを利用するようにした。
クライアントでは、ダウンロードした該当パッチファイルを現在の1MBファイルに適用できるようにした。

結果的に既存トラフィックの合計60%のコストを削減することができた。

最初に完成して配布した結果、既存トラフィックがむしろ3倍増え、一日で急いでロールバックされた。

既存のアップデートロジックがある特殊な状況で、直ちに3回以上アップデートを試みたのが問題だった。
- そのため、増分アップデートコードが3回以上動作し、異常なトラフィックが発生したのだ。
短期間の開発だったため、End-to-endテストを自動化ではなく手動で行って逃した問題だった。
- そして、既存のアップデートロジックをもう少し細かくチェックし、end-to-endテストを自動化で構成した。
今後、安定性を点検した後、再び配布した結果、上記のようにトラフィックをよく減らすことができた。

やはり昔ideで開発されたプログラムだったので、テストコードの挿入が難しかった。
- これもVS2019でgtestライブラリとnginxで自動化テストを行った。
この機能は、必ずサーバの状況とともにテストされなければならなかった。
- サーバー環境の具現が難しかった。すべての場合におけるパッチファイルを手動で生成することも難しかった。
- 自動化テストのために既存のci/cdにスクリプトを作成して入れることが難しかった。