この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは、坂巻です。
本記事はAWS re:Invent 2018のセッション「Best Practices for Running Oracle Databases on Amazon RDS」のレポートです。
概要
Amazon Relational Database Service (Amazon RDS) continues to be a popular choice for Oracle DBAs moving new and legacy workloads to the cloud. In this session, we discuss how Amazon RDS for Oracle helps DBAs focus their time where it matters most. We cover recent RDS Oracle features, and we go deep on key functionality that enables license optimization, performance, and high availability for Oracle databases. We also hear directly from an AWS customer about their journey to Amazon RDS and the best practices that helped make their move successful.
スピーカー
スピーカーは以下の2名です。
- Michael Barras - Senior Database Engineer
- Phil Eedes - Technical Architect, UK Ministry of Justice
Agenda
- Introduction -Amazon RDS
- Best Practices for Oracle DBAs
- Ministory of Justice migration story
レポート
Introduction -Amazon RDS
Managed databases on AWS
- Relational Databases
- Amazon RDS
- Amazon Aurora
- Amazon Redshift
- NoSQL
- Amazon DynamoDB
- Amazon ElastiCache
- Amazon Neptune
Amazon Relational Databases Service
- 簡単な管理
- マネージドインフラストラクチャ
- 数分で利用可能
- インスタンス間でのパラメータとオプションの管理
- Webコンソール、CLI、SDK、AWS CloudFormation
- スケーラブルで高速
- 32TBにスケーラブルなSSDバックアップストレージバースト可能またはプロビジョニングされたIOPS
- 1vCPU / 1GiBから128vCPU / 3,904GiBまで簡単なスケーリング
- 利用可能で耐久性がある
- 自動ホスト交換
- 管理されたバックアップ
- 耐久性のあるストレージ
- 安全
- デフォルトではVPC
- オンプレミスへのVPN /Direct Connect接続
- 安心して暗号化
- 通過中の暗号化
- 強力なアカウント管理
- 安価
- 利用分のみの支払
- CAPEXからOPEXにシフト
- 必要に応じて縮小
- 予約済みのインスタンスが利用可能
- 使用可能なライセンス（SE1、SE2）
- 持ち込みライセンス（SE1、SE2、EE）
Best Practices for Oracle DBAs
セキュリティ
不正アクセスの防止
Amazon Virtual Plivate Cloud
- セキュリティグループの入力/出力ルールを定義
- データベースをプライベートサブネットで維持
- アウトバウンド・ネットワーク・アクセス（UTL_SMTP、UTL_HTTP、データベース・リンク）を使用する場合の出力制御
SSLネットワーク暗号化
- すべてのOracleバージョンおよびエディションで使用可能
- TLS1.2（11.2EEおよび12.1+）
- AWSルート証明書を使用してクライアントウォレットを設定
RDSストレージ暗号化
- Amazon KMSインテグレーション
- 鍵の管理/持ち込み
- すべてのエンジン/エディション
- 低オーバーヘッド
- インスタンスの作成時に有効
- 既存のスナップショットを暗号化し、暗号化されたインスタンスとして復元
誤用の検出
データベース監査
- 標準および細粒度の監査をサポート
- OS / XMLからAmazon CLoudWatchログへ
- 12.2での統合監査
API監査
- AWS CloudTrail
- アカウントリソースに対するアクション
- 検出、分析、アラーム
パフォーマンス
パッチに関するデータを保持
- 四半期ごとの新リリース
- PSU（11.2,12.1）またはRU（12.2）
- DescribeDBEndineVersion
- エンジンリリースノートのパッチ構成
- カスタムパッチも1回限りのパッチもなし
- アップグレードをテストしてください！！
アップグレードのベストプラクティス
アップグレード前
- RDSドキュメントの復習する
- パラメータとオプショングループの事前作成（メジャーバージョンのアップグレード）
- オブジェクトが有効でデータベースリンクに到達可能であることを確認する
- 十分なスペースを確保する
- バックアップを取る
アップグレード後
- アプリケーションをテストする
- ポイント・イン・タイム・リカバリによるロールバック
パフォーマンス
ワークロードを知っている
- 破棄可能なインスタンスタイプ
- 通常は安定しており、周期的な短いスパイクを伴う
- 拡大縮小
- 予測可能で着実に増加する周期的なピーク
- リザーブドインスタンス
- 定常状態、エンタープライズアプリケーション
ワークロードのスケール
破棄可能なインスタンスタイプ
- 開発/テスト
- 小規模な本番データベース
- ベースラインCPUパフォーマンス
- CPUクレジットによるバーストパフォーマンス
スケールアップとダウン
- 周期的なピークを持つ予測可能なワークロード
- マルチAZでの高速フェイルオーバー
- 応答時間を最適化する
- CPU /ハイパースレッディングを選択
予約済みのインスタンス
- 定常状態の作業負荷
- 1年間と3年間の期間
- 前払いなし、一部前払い、またはすべて前払いなし
- 最大69％の節約
なぜCPUが100％なのか？
RDS拡張監視
- プロセス単位のホストメトリック
- AWSコンソールでの表示または監視システムへのプッシュ
- 1-60秒の粒度
- 15時から開始
- トラブルシューティングの際に1秒以内にダイヤル
RDSパフォーマンスインサイト
- データベース負荷の測定、平均アクティブセッション
- すべてのRDSエンジン
- 要求されない
- AWSコンソールでの表示または監視システムへのプッシュ
アベイラビリティ
RDSマルチAZ
- フルマネージドなセカンダリリージョン
- 明確なEC2 / EBSリソース
- 同期ストレージレプリケーション
- 1-2分でフェールオーバー
- クラッシュリカバリ
- CNAME伝播
- 99.95％の稼働時間／月のSLA
複数のAZのベストプラクティス
- シングルAZのクリニカルワークロード
- マルチAZ - 重要な作業負荷
- 対称構成 - 「フェールバック」なし
- 接続プールはDNSをキャッシュするのではなく、再接続が必要
- テストパフォーマンス
- アプリケーションの耐性をテストする→再起動する
- リージョン間/ DRのカスタマー管理による論理複製
RDSバックアップ
自動バックアップ
- バックアップ中の毎日のスナップショット
- 5分ごとにS3にログをリロード
- 保持期間：1-35日
手動バックアップ
- いつでもスナップショットを取得
- 削除するまで保存
スナップショットから復元
- 任意のスナップショットから復元
- スナップショットを他の地域やアカウントにコピー
ある時点から復元
- バックアップを保持して何秒にも復元
- 利用可能な地域/アカウント
- 修復可能な最新の時間は通常<5分
ベストプラクティスのバックアップと復元
- データロードのバックアップを無効にする（ノーアカイブモード）
- 警告：既存の自動バックアップを削除する
- 重要なワークロードのバックアップを有効にする（アーカイブモード）
- バックアップ時間を低使用時間に設定
- 手動スナップショットをとって、PiTRウィンドウを減らす
- リストアを使用してアップグレード/パラメータ/アプリの変更をテスト
- スナップショットを他のアカウント/地域にコピー
Backup and resanges
- スナップショットを他のアカウント/地域にコピー
コンフィギュレーション
スタンダード版を再考する
RDS Muti-AZによる高可用性
- 同期レプリケーションと自動フェイルオーバー
- 99.95％の稼働時間のSLA
- 独立したインフラ
Amazon KMSによるRDSストレージ暗号化
- AES-256暗号化
- 持ち込みの鍵を利用
RDSによるチューニング強化された監視とパフォーマンスの分析
- プロセス単位のホストメトリック、最小1秒までの粒度
- データベースの負荷とアクティブなセッションを分析
バージョンを再考
最新の状態
- 12.2.0.1が利用可能になりました！!
- 拡張サポート終了時に廃止された古いリリース
- 30〜60分間の停止によるアップグレード
安全な滞在
- 最新のPSU / RU四半期
- JVM / Spatial / Locator / Multimediaに必要なアップデート
- 5〜10分の停止でアップグレード
インスタンス間でパラメータを管理する
- 同様のインスタンス間で構成を管理するために、sinbleグループを使用
- 数式表現のサポート
- テストパラメータの変更
- 静的メモリ関連のパラメータを変更するためにフェールオーバーなしでリブート
Ministory of Justice migration story
データベース移行に関する考慮事項
対象：RDS SE対EE対EC2
- ライセンス
- 使用される特徴
- バックアップと復元
- パフォーマンスと監視
方法
- 現実のもの（サイズ、バージョン、接続性）
- ヘルスチェックと修復
- エンディアン変換
- 停電許容値
- ライブへのルート
データベースの移行方法
- AWS上のEC2 Migration Server（Oracleクライアント）
- RDSでターゲットDBインスタンスを作成（AWS CloudFormation）
- ソースDBでのDataPumpエクスポート
- EC2サーバーへのSCPファイル
- ファイルをRDSインスタンスに転送する（PERLスクリプト）
- RDSでのDataPumpインポート
- 接続を再確立する
The UTL_FILE challenge(for FTP)
UTL_FILE challenge（FTPの場合）
The challenge
- DBファイルシステムのファイル転送
- UTL_FILEおよびOracleディレクトリはRDSで完全に機能
- ディレクトリの場所が公開されていない
- 廃止予定のSHA-1
The solution
- Oracle 12cへのアップグレード
- APEXをインストール
- SHA-2（SHA-256）ハッシュを使用
- ウォレットをアップロードするためにperlを使用
- S3用PL / SQLラッパーの作成
- Delete / Get / List / Put
12c〜9iのDBリンク
The challenge
- SHA-2のアップグレードには12cが必要
- DBには依然として9iへのDBリンクが必要
- Oracleデータベースは2versとのリンクを許容する
The solution
- Intoduce Interim "HOP" db（v11g）
- HOPデータベースでのAPIのレプリケート
Verdic
- 計画は報われる - AS-ISを理解する
- 方法論を証明し改善する
- RDSサポートは、応答性と有効性の両方を備えている
- AWS上で約50％のパフォーマンス向上
さいごに
情報量が多く、濃い内容のセッションでした。業務でOracleを利用しているので参考になるセッションでした！
3
