見出し画像

愛（AI）と共に：📙AWSのRDSは信頼できるがコストが高い！😭代替案を模索する💦

watabin

データベースの管理運用は地獄の苦しみ。
24時間稼働で壊れ無い事を求められ、仮に壊れても即復旧などを、気軽にお願いされますが、要求に沿った仕様を実現できるPCスペックの見積もり、こちらも気軽に提出すると普通に仕事を失います（失注）。
※しかも人件費も別途かかるのだよ…🥺
ただ、一度「顧客が絡んだデータベースが落ちる」を経験すると、そのコストの正当性を理解してもらえる。
データベース運用管理はそんな世界です🌏

それをAWSのRDS（リレーショナル・データベース・システム）は最高のコストパフォーマンスで提供してくれるのですが、DB運用管理を含めての価格は月＄200（3万円）。壊れ無いDBの品質までも月＄20（3千円）くらいかかります。（扱うデータが増えれば当然コストは増えます。またRAID5仕様のパソコンがざっくり100万円計算で、x6台を初期費用とした時のコスト比較なら、RDSは破格に安いと思えるでしょう）

個人で試すとか、動作確認のテスト程度で使うなら、もう少し安く抑えたいは心情です。（切実）
そこで、壊れても良い前提レベルの代替データベース（DB）案を検討してみました。
本文で紹介するDynamoDBは壊れる事は無いですが、MySQLとは仕様が違うので本番環境に移行した際に、パラメータ（設定値：サーバー名やアカウント情報）の変更で済まないのが悩みどころでしょう。


📕EC2＋MariaDBで代替

「テストは極限まで安く、本番は信頼のRDS」という使い分けは、個人開発や新規プロジェクトのスモールスタートにおいて理想的な戦略。（たぶん）
小規模での運用なら、t3.nano での運用で十分。いくつか実戦的なアドバイスというかヒントをまとめてみました。

1. t3.nano (0.5GB RAM) での MariaDB 運用術

メモリが 512MB というのは、OS（Amazon Linux等）を動かした上でDBを走らせるにはかなりタイトな環境です。以下の工夫をすることで、t3.nanoでも安定して稼働させることが可能です。

スワップ領域（Swap）の作成は必須

メモリ不足でプロセスが強制終了（OOM Killer）されるのを防ぐため、最低でも 1GB〜2GB程度のスワップファイル を作成しておくことを強くおすすめします。

Bash

# 例: 2GBのスワップファイルを作成
sudo dd if=/dev/zero of=/swapfile bs=128M count=16
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

MariaDBの設定最適化

デフォルト設定ではメモリを使いすぎるため、/etc/my.cnf 等でバッファサイズを絞ります。

  • innodb_buffer_pool_size: 128MB〜256MB程度に制限。

  • performance_schema: Offにする（これだけで数十MB浮きます）。

2. コストの比較（目安）

t3.nano を EC2 で動かした場合の月額料金イメージです。 ※バージニア北部リージョン、オンデマンド料金で計算。

サービスインスタンス代月額目安備考
RDS (Aurora)約 $200：約 $200~壊れないDB、メンテも簡単（管理が楽）
RDS (db.t3.micro)約 $12.41：約 $15~ストレージ・バックアップ代別
EC2 (t3.nano)約 $3.80：約 $5~ストレージ (EBS) 代別

月間 1,500円〜2,000円程度の差 が出ますので、テスト期間が長くなるほど EC2 自前運用のメリットが出てきますね。

3. NoSQL という選択肢：DynamoDB の「真の無料枠」

もし「PythonやGoからアクセスできれば良い」という条件で、リレーショナル（表結合など）が必須でないなら、Amazon DynamoDB は検討の価値があります。

  • コスト: 25GBまで永久無料。

  • メリット: サーバーの管理（t3などのインスタンス管理）が一切不要。

  • SDK: boto3 (Python) や aws-sdk-go-v2 (Go) で非常に簡単に扱えます。

テスト運用期間中に「インスタンスの生存確認」すらしたくない場合は、DynamoDB にデータを投げておくのが最も安上がり（ほぼ0円）で済みます。

結論としてのステップ案

  1. 今の RDS (db.t3.micro) で数日動かし、設定変更後のコストの減り具合を確認する。👈体感できるまで良い。5分動かすだけでもデータは取れる。

  2. それでもコストが気になるなら、t3.nano の EC2 を立てて Docker 等で MariaDB を起動し、Python/Go から接続先を切り替える。

  3. 本番リリースが見えた段階で、データをエクスポートして RDS へ移行する。

顧客からお金をいただくサービスであれば RDS の「マネージド（管理はお任せ）」という安心感にはそれだけの価値があります。バックアップ、パッチ適用、マルチAZ構成の組みやすさなど、運用が始まってからは RDS のありがたみが身に沁みるほど実感できると思います。

それでも、まずは t3.nano での「限界突破運用」を試してみるのは、技術的な勉強としても面白いと思います！


📘DynamoDBで代替

DynamoDBは、MySQLのような「表」のイメージで入ると、キーの概念で最初につまずきやすいと思います。

基本的には、「テーブルを作る」→「データを出し入れする」という流れで合っていますが、DynamoDBにおいて「キー」は単なる名前ではなく、データの保存場所を決める超重要な役割を持っています。

初心者の方向けに、最もシンプルで汎用的な設定方法で解説します。

1. キー設定：何を入れるべきか？

テーブル作成時に聞かれる「パーティションキー」と「ソートキー」は、以下のように考えると失敗しません。

パーティションキー（必須）

  • 役割: データをどのサーバーに保存するか決めるための「住所」です。

  • 入れるべき値: 重複しない一意のID（例：userId, deviceId, orderId など）。

  • 型: 文字列（String）にしておけば間違いありません。

ソートキー（オプション）

  • 役割: 同じパーティションキーの中で、データを並び替えたり、さらに絞り込んだりするための「枝番」です。

  • 入れるべき値: * 不要な場合: 空欄（設定しない）でOKです。

    • 使う場合: 日時（timestamp）やカテゴリ名を入れるのが一般的です。

  • 例: * パーティションキー：userId

    • ソートキー：createdAt

    • これで「特定のユーザーの、特定の期間のデータ」を高速に取り出せます。

2. 最も簡単な始め方（おすすめ設定）

まずは「練習用」として、以下のように設定してテーブルを作ってみてください。

  • テーブル名: test-table

  • パーティションキー: id (型: 文字列)

  • ソートキー: (設定しない)

  • テーブル設定: 「デフォルト設定」でOKです。

ポイント： DynamoDBは、MySQLと違って**「事前にカラム（列）を定義する必要」がありません。** パーティションキー（とソートキー）さえ決まれば、あとの項目はデータを保存する時に、PythonやGoから自由に（例えば {"id": "001", "name": "Gemini", "score": 100} のように）投げ込むだけです。

3. Python (boto3) での使い方の基本

テーブルさえできれば、コードからは非常にシンプルにアクセスできます。

Python

import boto3

# DynamoDBに接続
dynamodb = boto3.resource('dynamodb', region_name='us-east-1') # リージョンはご自身の環境に合わせて
table = dynamodb.Table('test-table')

# 1. データを保存する (Put)
table.put_item(
   Item={
        'id': 'user_001',      # これがパーティションキー
        'name': '田中太郎',     # あとは自由に増やせる
        'age': 30
   }
)

# 2. データを取得する (Get)
response = table.get_item(Key={'id': 'user_001'})
print(response['Item'])

4. なぜ「テスト運用」に向いているのか？

  1. オンデマンド料金設定: テーブル作成時の設定で「オンデマンド（オンデマンド）」を選択すれば、アクセスがない時間は0円です。t3.nanoのように「インスタンスが動いているだけで課金」されることがありません。

  2. 永久無料枠: 25GBまでは無料枠に収まるので、個人開発のテストデータ量なら実質タダで使い続けられます。

「SQLの WHERE id = 'xxx'」が「DynamoDBの Key={'id': 'xxx'}」に変わるだけ、と考えると少しハードルが下がりませんか？

まずは パーティションキー id (String) だけのテーブルを作って、Pythonから1件データを放り込んでみるところから始めてみるのはが良いでしょう。


📙EC2：自前の環境で快適・安全にするポイント

テストフェーズで月額3,000円前後の固定費は確かにもったいないと思い。

EC2（ t3.nano や t3.micro ）に MariaDB を導入すれば、「使った分だけ」かつ「インスタンス料金のみ」の最小構成になります。

実際に運用してみて気づかれるかもしれませんが、EC2自前運用の「テスト環境」をより快適・安全にするためのポイントがあるのでいくつか整理しました。

1. メモリ不足対策（t3.nanoの場合）

もし t3.nano (512MB RAM) を使うなら、MariaDBが動いている最中にメモリ不足で落ちるリスクがあります。

  • スワップ作成: まだ設定していなければ、1GB程度のスワップ領域を作っておくと安心です。

  • 不要な機能の停止: performance_schema=OFF を設定ファイル（my.cnf）に書き込むだけで、メモリ消費を数十MB節約できます。

2. 接続設定の確認（セキュリティグループ）

PythonやGoのプログラムを自分のPC（ローカル）からEC2のDBに繋いでテストする場合：

  • セキュリティグループ: EC2のインバウンドルールで 3306ポート を解放する必要がありと思います。

  • ソース指定: 0.0.0.0/0（全解放）にせず、自分のグローバルIPアドレスのみを許可するように設定しておくと安全です。

3. 「いつの間にか高くなる」のを防ぐコツ

EC2自前運用で意外と見落としがちなのが EBS（ストレージ） です。

  • スナップショット: RDS同様、EC2のボリュームも手動でスナップショットを撮りすぎると課金が発生します。

  • 終了後の削除設定: 将来EC2を削除する際、EBSも一緒に消える設定（Delete on Termination）になっているか確認しておくと、ゴミが残らずに済みます。

4. 本番への「戻り道」を意識する

テストがうまくいき、いざRDS（本番）へ移行する際は、以下のコマンド一発でデータを移行できます。

# EC2側でダンプ（書き出し）
mysqldump -u [user] -p [database_name] > backup.sql

# RDS側へインポート（読み込み）
mysql -h [RDSのホスト名] -u [user] -p [database_name] < backup.sql

ここまで来れば、コストを抑えつつ開発に集中できる環境が整ったと言えるでしょう。
MariaDBの設定や、外部（Python/Go）からの接続で出るエラーをチェックする程度の開発段階では、高いRDSまでのスペックは不要かも知れません。


📗使用料の高いAuroraデータベースの必要性

「なぜこんなに高いサービス（Aurora）が、世の中でこれほど求められているのか」

結論から言うと、企業がAuroraに高いお金を払うのは、「データの絶対的な安全性」と「24時間365日の無停止運用」を、自前で構築・運用する人件費やリスクと比較したときに、圧倒的に自前よりAuroraの方が安い（または確実である）」からです。

1. 「絶対にデータが消えない」超強固なストレージ構成

個人開発やテスト環境であれば、「最悪、数日前のバックアップから復元すればいい」で済みますが、決済システムや会員情報を扱う商用サービスでは1秒のデータ消失も許されません。

  • 3つのデータセンターに6つのコピー: Auroraはデータを保存する際、自動的に3つの異なるデータセンター（Availability Zone）にまたがって、合計6つのコピーを同時に作成します。

  • データセンターが2つ吹き飛んでも平気: 万が一、大規模な災害でデータセンターが2つ同時に完全にダウンしても、データの書き込みや読み込みを継続できる仕組み（クォーラムモデル）が標準で組み込まれています。

  • ディスクの自動修復: バックグラウンドで常にデータの破損チェックを行っており、壊れたブロックを見つけると自動的に正常なコピーから修復します。

これを自前のEC2で構築しようとすると、サーバーを何台も同期させ、監視プログラムを書き、異常検知の仕組みを作る必要があり、インフラエンジニアの人件費だけで莫大なコストになります。

2. 障害発生時の「自動フェイルオーバー」が爆速（30秒未満）

自前で立てたEC2のDBが深夜2時にメモリ不足やハードウェア障害でクラッシュした場合、手動で復旧させるか、自動復旧の複雑なスクリプトを組んでおく必要があります。

  • 30秒未満で勝手に切り替わる: AuroraはメインのDB（プライマリ）が死んだことを検知すると、自動的に用意されている待機系（レプリカ）をメインに昇格させます。アプリ側はほぼダウンタイムを感じることなく接続を継続できます。

  • クラッシュリカバリが不要: 通常のMySQLなどは強制終了後に再起動すると、ログの整合性をチェックする「クラッシュリカバリ」に数分〜数十分かかります。Auroraはストレージの構造が特殊なため、再起動が一瞬で終わります。

3. 「データベースの限界」を超えやすいアーキテクチャ

システムが成長してアクセスが爆発した際、最もボトルネック（処理の限界）になりやすいのがデータベースです。

  • 計算（CPU）とデータの分離: Auroraは「SQLを処理する頭脳（インスタンス）」と「データを保存する箱（ストレージ）」が完全に分かれています。

  • 読み取り専用大臣を15台並べられる: データの読み取り専用サーバー（リードレプリカ）を最大15台まで一瞬で追加できます。どれだけ読み取りアクセスが集中しても、メインの書き込みサーバーに一切負荷がかかりません。

  • ストレージの自動拡張: 事前に「何GB使うか」を決める必要がなく、データが増えた分だけ勝手にストレージが最大128TiBまで自動で広がります。ディスク容量不足でシステムが止まる心配がありません。

4. チューニングなしで「圧倒的に速い」

商用データベース（Oracleなど）並みのパフォーマンスを、使い慣れたMySQLやPostgreSQLのコードのままで出せるのが強みです。

  • 通常のMySQLの最大5倍、PostgreSQLの最大3倍の速度: データの書き込み時に「ログだけを転送する」というクラウドに最適化された特殊な実装をしているため、ディスクI/Oの無駄が徹底的に排除されています。

料金の考え方：インフラ代 vs 人件費・機会損失

個人で使うと「月数千円〜数万円」は高く感じますが、企業目線だと以下のような天秤になります。

  • 自前（EC2等）で同等の可用性を目指す: 熟練のインフラエンジニア（年収数百万円〜）を雇い、24時間監視体制を敷き、何週間もかけて冗長化システムを設計・テストする。

  • Auroraを使う: 月2万〜10万円払うだけで、AWSが世界最高峰の可用性を勝手に保証・運用してくれる。

さらに、サービスが数時間停止したときの「売上の機会損失」や「信用の失墜」を考えると、Auroraの利用料は「最も安上がりで確実な保険代」になるため、爆発的な需要があるのです。

「テスト時はEC2（t3.nano等）で節約し、本番では信頼性を買うためにRDS/Auroraへ移行する」という選択は、正しいアプローチだと思えます。

いいなと思ったら応援しよう！

この記事が参加している募集

#

やってみた

12万件