AWSからOCIへ

もともとこの技術ブログはAWSを利用してEC2,RDS(MySQL),S3で展開したプロジェクトでした。
ある日,偶然OCIのことを知ったのですが,魅力的なポイントがたくさんありました。
まず,現時点ではフリーティア期間が無制限で,OCIのA1 Flexの仕様はAWSのt2.microとは比較にならないほどでした。

バックエンド開発者の役割は基本的なCRUD構成で終わるのではなく,最小限のコストで最大のトラフィックを受け取ることです。

貧乏な開発者志望の私はすぐに移住を準備することになったが,OCIがハニーであることは私だけ知らなかったということに気づいた。OCIはアカウントを作成する時,AWSとは違ってリージョンを選択して作成するのですが,ソウル,東京はすでに満席で,春川リージョンに追加で作成することになりました。

ワクワクしてインスタンスを作成しようとした瞬間,

可用性ドメインAD-1でVM.Standard.A1.Flex構成の容量が不足しています。他の可用性ドメインにインスタンスを作成するか,後で再試行してください。

というエラーが発生し,簡単に調べてみると,プリティアに割り当てられた容量が全部埋まって空きができるまで(未使用でインスタンスを削除したり,他の理由で)A1インスタンスを生成することができませんでした。

大した金額ではありませんが,AWSはIPv4使用料金とフリーティアに含まれないRoute53の費用で私の小遣いをどんどん奪っていたので,焦った私はスクリプトを作り始めました。

しかし,だいたい12時間くらい回してもインスタンスは生成されず,スクリプトを組んで得た情報によると,運が悪ければ1週間くらいはあれを回し続けなければインスタンスを生成することができないという回答が大半でした。

他の方法がないかと探していたところ,フリーティアではなく決済情報を登録して有料会員に移行すれば,リージョン内のフリーティア割り当て量に関係なく生成が可能だという情報を得て,「!

この金額は決済確認用に決済された後,すぐにキャンセルされる。

すぐに有料会員への移行を行い,5時間ほど経った後,移行が完了したというメールを受け取った。

フリーティアで提供されるA1インスタンス(4cpu,24GB RAM)の最大仕様を二つに分けて(3cpu/18GB,1cpu/6GB)それぞれブログ用,RDSの代わりに使うDB用に作成した。

AWSを離脱するためにDBをRDSではなくOCIフリーティアが提供するRDBMSに変えようかと悩みましたが,技術面接が迫っている私にはMySQLベースのDBをOracleベースのDBに移行する過程に費やす時間がありませんでした。

まず,DBを接続する前にOCIに生成したブログインスタンスにDockerイメージをアップロードする過程から行いましたが,この過程でいくつかの小さなトラブルがありました。

1.ドッカーイメージが開かない,EC2のt2.microはx86ベースなので,すでにビルドされてdocker hubに上がっているイメージはlinux/amd64でA1 flexのARM環境で開かなかった。
解決方法はとても簡単で,イメージビルドをlinux/arm64ベースにすることで解決しました。

2.ビルドするブランチを間違えて,既存のDBのスキーマ構造と違いがあり,A1インスタンスでdocker-compose upでサーバーを実行するたびにDBが初期化される。
上記で些細なトラブルと書きましたが,この問題はかなり困惑しました。まだ,投稿も少なく,重要な情報はないのに,テスト投稿でいっぱいのブログを見て深いため息をついた。幸い,RDSのスナップショット機能を使ってworkbenchでDBをlocal exportした後,それを元のRDSインスタンスに接続してimportする方法で解決しました。

しかし,このようなトラブルが悪いことばかりではありません。
私が一時期楽しんだ鉄拳を筆頭にした格闘ゲームには次のような名言があります。

知らぬが仏,知らぬが仏

本当にその通りだ。開発を初めて始めた時,何も知らずにRDSを使ってみようとGPTとあちこち弄り,設定を間違えて48時間余りの時間で40$の請求を受けた自分を思い出しました。今回のプロジェクトでその恐怖を克服できず,コスト発生に怯え,RDSではなくローカルDBを使ってたら復旧できなかった問題であり,Dockerイメージの移行が終わった後,DBインスタンスの設定をする時も参考になって,cronで自動バックアップをするように設定しました。

前回書いたTrade-Offがここでも改めて思い出しました。

コスト vs 煩わしさ

の対決ではないかと思う。 最も有名な管理型データベースであるRDSを使うことで管理の手間を減らす代わりにコストを払うのか。

それとも,別個のインスタンスでDBを直接管理してコストをなくす代わりに,バックアップ,セキュリティなどの手間を負うのか。

結論として,今の私は費用が発生する余地をできるだけなくし,多少の手間は取ることにしました。

とにかくCI/CDパイプラインをあらかじめ構成しておいたおかげで,簡単なGitHub Actionsの修正とdocker-composeの修正だけで簡単にOCIに移行することができたし,面接後に時間があれば,唯一残っているS3も何らかの方法で修正をして完全にAWSを脱AWSしてブログに限ってはコスト問題から解放されるのではないかと思います。