「起動してるだけでお金がかかるだと…？」
オンプレ時代。
DBサーバーの稼働コストは、ハードを買って終わりだった。
サーバーは24時間365日動いていて当たり前。
電気代？ラック費？そんなのインフラ担当の話だろ？とさえ思っていた。
しかしADBは違った。
「CPU使えば使うほど課金されます」
「DBを起動している間だけ、従量課金です」
「止めれば課金止まります(ストレージ部分以外)」
……なるほど、ADBは性能チューニングだけでなく、コストチューニングも要求される世界だった。
CPUとストレージの“見える化”
ADBでは、以下のようなリソースを秒単位で監視し、課金対象になる：
- CPU時間（ECPU単位）
- ストレージ使用量（ADW:1GB単位 / ATP：1TB単位）
- データ転送コスト（Egress）
※ OCIリージョンから外部（インターネットなど）へデータが転送される場合、転送量に応じて料金が発生することがあります。
この世界（ADB）には2人の強者（サービスタイプ）がいる
ADW（Autonomous Data Warehouse）は、大軍勢の情報を一気にさばく"情報参謀"
ATP（Autonomous Transaction Processing）は、最前線で取引や更新を俊敏にこなす"前線兵"だ。
どちらも同じ国（ADB）に属すが、戦い方はまるで違う。
任務が違えば、装備も戦術も違うので入隊（ADBを構築）する時に選ぶ必要があるのだ。
ちなみに、OCIコンソールには、CPU使用量やストレージのグラフが可視化されており、
「昨日はCPU 4ECPU × 6時間使ってますね」
「ストレージは75GB使用中です」
…みたいに、めちゃくちゃ正確に“見えてしまう”。
「止め忘れ」で数万円飛ぶのも珍しくない
開発環境でADBを起動したまま帰ってしまい、
月末に請求書を見て青ざめる――これはクラウドあるあるだ。
でも安心してほしい。
OCIコンソール上で自動起動・停止のスケジュール登録が出来るのだ。
ここで注意！時間指定は、容赦なく"UTC"基準だ。
「朝9時に起動！」と思って9:00に組むと、実際は日本時間18時に動き出すーー
まるで時間差魔法の罠だな。
正しくは、"日本時間からマイナス9時間"して設定する必要がある。
「DBの起動・停止を管理する」なんて、オンプレ時代では想像もしてなかった。
Auto Scalingで“足りない”ときも安心
ADBでは、Auto Scaling機能 をONにしておけば、
- 負荷が高まったらECPUを一時的に増強
- 負荷が下がったら自動的に元に戻る
- 使用した分だけ1秒単位で課金（最大3倍まで）
つまり、最小構成で普段は安く、ピーク時だけ高性能というチート技が使える。
だが注意点もある：
- Auto Scaling中も使った分はちゃんと課金される
- スケールアップした分が“永続化”されるわけではない
DBAの新スキル「コスト感覚」とは
クラウドDBAには、以下のようなスキルが求められるようになった：
「このバッチ、深夜に回した方がコスト安くない？」
「今週はアクセス多そうだからAuto ScalingをONにしよう」
「開発DB、今日は使わないから止めよう」
つまり、DBAがコストの調整弁になれる時代が来たということだ。
そしてそれは、組織全体の最適化につながる
コストと性能のバランスを取れるDBAは、
インフラ担当、アプリ担当、経営陣との架け橋になる。
「どこに、どれだけ、お金を使うか」
それを理解してコントロールできるDBAは、経営に貢献する技術者 に進化できる。
昔は「止めたら怒られた」
今は「止めないと怒られる」
それがクラウドの世界だ。
「高性能」だけじゃなく「高効率」なDB運用――
それが、ADB時代のDBAに求められる力だった。
次回予告
第9話｜いきなり災害対策やれと言われて、ADBで涙が出た件
次回、上司からの無茶振り「明日までにDR構築」が俺を襲う――
だがADBのAutonomous Data Guardは、ボタンひとつでその無理ゲーを神ゲーに変えた！