やったこと
- サービスをメンテナンスイン
- ConoHaのオブジェクトストレージから全オブジェクトをダウンロード
- ダウンロードしたオブジェクトをS3にSync
- オブジェクトストレージへのアクセスをS3に変更したアプリケーションをデプロイ
- オブジェクトのGet/Putのみを行っていたため最小限の変更で済んだ
- オブジェクトへのプロキシー（Nginx）のオリジンをS3に変更
- サービスをメンテナンスアウト
規模はオブジェクト数万、容量数GB程度。 この程度なら力業でオブジェクトをコピーできる。
今すぐに移行先を（自分が多少触ったことがあるという理由で）AzureのBlob Storageにする、としてもそれほどのインパクトはさそうだ。
一般的なサービスであれば、S3が落ちたら巻き込まれで停止してもいいだろうと考えているが、それが許されなかったりするような場合に複数のオブジェクトストレージサービスにオブジェクトをミラーリングしておき、場合によって接続先を切り替えるようなことは、他の分野のフェールバックよりは平易に行えそうだと感じた。
変更点と留意点
サービスのアプリケーションへの変更と移行作業は非常にシンプルで上の図程度だった。
変更を平易に済ますためには以下のような点に留意しておきたい。
- オブジェクトのI/Oの処理は1か所に集約する
- オブジェクトに関する情報は オブジェクトキー の形で保持する
- 移行に使うソフトウェアは移行規模に向いたものにする
オブジェクトのI/Oの処理は1か所に集約する
当たり前だが、ある同種のリソースへのアクセスの実装は1か所に集約、汎用的なインタフェースとしておきたい。
正直なところ『リポジトリパターン』とかがどの程度テスト以外の実際の便利に寄与するかは分からない部分があるのだけれど、 いざ「永続化先を変更したい」となった時にリソースへのアクセスの実装が散っていたら詰む。
基本は大事にしたい。
オブジェクトに関する情報は オブジェクトキー の形で保持する
オブジェクトのI/Oの処理 に通じるものがあるが、アプリケーションがオブジェクトに関して持つ情報はオブジェクトキーにしておきたい。
今回はそうだったので、オブジェクトのI/Oの処理を変更するだけで永続化先の変更に対応できた。
全然別のアプリケーションでURIでオブジェクトの情報を持たせているものがあって「失敗したなぁ」と思っている。
そのアプリケーションのオブジェクトを別のサービスに変更したいとしたら、それらの情報のマイグレーションも行わなくてはならない。
ロックインされているということだ。
移行に使うソフトウェアは移行規模に向いたものにする
移行に当たって、今回はローカルマシンに Cyberduck でダウンロード、そこから AWS CLI でアップロードしたが、Cyberduckでのダウンロードはよりオブジェクト数が多いと厳しそうだった。
数万オブジェクト程度だったが、不安感のある動作だった。
多数のファイル操作には向いていないのかもしれない。
こんなエラーコードははじめて見た。
余談
以前ConoHaのオブジェクトストレージのサービスレベルが低い旨を記事にしているが、その状況が改善しないので仕方なく移行対応した形になる。
ConoHaのVPSは非常に良いものなのだけれど、周辺のマネージドサービスはコアな用途に使うには少々頼りない。
オブジェクトストレージに関しては、ConoHaのVPSからでもインターネット経由でのアクセスとなるため、使用することに特にこれといったメリットはない。 （他のマネージドサービスではインターネットに出ないアクセスができるものもある）
先の記事にも書いたが、どこであろうとコアサービス以外は開発・運用のリソース投入が限られているはずなので、大事な用途には安定の実績があるサービスを使用するようにしたい。
