🔴
Redshiftのノード構成変更:dc2.large 3台からra3.xplus 1台へ
はじめに
弊社でデータ分析基盤として利用しているRedshiftのストレージ容量が枯渇してきたため、ノード構成の変更が必要となりました。これまでは比較的少ないデータ容量に対応するため、DC2インスタンスを使用していましたが、次のスケールアップでdc2.largeが4台になることを考慮し、RA3インスタンスへの移行を検討しました。本記事では、その検討内容と実際の移行作業について記載します。
参考情報
DC2とRA3を選ぶ基準として参考資料のように考えると良いそうです。Redshiftを採用した当時はデータ量が少なかったため、DC2を選択しました。今回データ量が増えてきたので、RA3への移行を検討しました。
現状分析
現在の環境
- ノード構成: dc2.large 3台
- ストレージ使用状況: 480 GB 中 477.08 GB 使用(約99.4%)
- データ増加率: 月間約5~10GB
- 月間コスト: 540USD/月(0.25USD/h x 720h/月 x 3台)
- CPU使用率: 平均30%程度
要件
- データ量は継続的に増えていく
- CPU負荷は比較的低い
構成オプションの比較
前提条件
- リージョン: バージニア北部
オプション1: dc2.large x 4台(スケールアップ)
- コスト: 720USD/月 (0.25USD/h x 720h/月 x 4台)
- ストレージ容量: 640GB (160GB x 4台)
-
性能:
- CPU: 8コア
- メモリ: 60GB (15GB x 4)
- I/O: 0.60 GB/s
オプション2: ra3.xplus x 1台(ノードタイプ変更)
-
コスト:
- オンデマンド: 781.92USD/月 (1.086USD/h x 720h/月)
- リザーブドインスタンス利用: 523.25USD/月 (1年全額前払6,279USD / 12ヶ月)
- ストレージ: 12USD/月 (0.024USD/GB x 500GB)
- ストレージ容量: 4TB
-
性能:
- CPU: 4コア
- メモリ: 35GB
- I/O: 0.65 GB/s
ra3.xplusの選択理由
- コスト効率: リザーブドインスタンス利用で長期的なコスト削減が可能
- 拡張性: 4TBの大容量ストレージにより、将来の成長に対応
- 性能バランス: 現在のCPU使用率を考慮すると、4コアで十分対応可能
- 新機能: AQUAなどRA3でのみ使える高度な機能が利用可能
移行手順
-
事前準備:
- クラスターのスナップショットを作成(所要時間:約8分)
-
クラスター変更:
- AWSコンソールからクラスター構成を変更(所要時間:約9分)
- 「アクション」-> 「サイズ変更」へ移動
- 「クラスターをサイズ変更」で「従来のサイズ変更」を選択
- 「新しい設定」でノードの種類を「ra3.xplus」、ノード数「1」を選択
- 「クラスターをサイズ変更」で決定
- AWSコンソールからクラスター構成を変更(所要時間:約9分)
-
検証:
- 移行後のデータ整合性確認
- クエリパフォーマンスの確認
最後に
ra3.xplusへの移行により、ストレージ容量の問題を解決しつつ、将来の成長に対応できる柔軟な環境になりました。ノードタイプの変更で数時間かかることを覚悟していたのですが、わずか10分程度で終わったのは驚きました。リザーブドインスタンスの利用によってコストを抑えることができ、新機能も使えるようになったのでこれからさらに活用していきたいと思います。
株式会社ウェイブのエンジニアによるテックブログです。 弊社では、電子コミック、アニメ配信などのエンタメコンテンツを自社開発で運営しております! ve.jp/service/
Discussion