当記事は、2025/6末時点のマニュアル情報や実機検証に基づき記載しています。
最新のサービス内容についてはAWS/IBMの最新情報をご確認ください。
AWSサイト Amazon RDS for Db2
IBMサイト Amazon Relational Database Service (RDS) for Db2
当記事は、特定の団体の意見を代表したり、正式なレビューを受けたものではありません。一個人が知見を残すために記載しており、記載誤りや古い情報などを含む可能性があります。重大な記載内容の誤り等、お気づきの点あればご一報いただければ幸いです。
概要
・Amazon RDS for Db2 は2023/11/27に発表されたばかりのサービスです。1インスタンス内に複数DBを構成できるようになったのが2024/12頃で、今後も監視機能など、機能拡充が期待されるサービスです。
・オンプレDb2サーバーからAWS RDS for Db2 へ移行する際の主だった考慮事項やリファレンスをまとめました。利用中のDb2環境の移行など、必要構成、見積もり等の参考になれば幸いです。
・当記事は現行運用環境であるPower Systems AIX のDb2環境を基準にシステムリニューアル検討を行った際の知見をまとめたものですが、IA環境からのマイグレーションや、新規構築案件などでも同様に参照いただけると思います。カテゴリごとリファレンスURLをあげていますので、ご参照ください。
当記事の前提・環境など
・移行元環境: IBM Power Systems + IBM AIX + IBM Db2
・移行先環境: AWS RDS for Db2 (db.t3.small 1core/2vCPU/2GiB mem)
(OS環境の違いは、データ移行方式や運用シェルの改修等に影響があります。適宜ご自身の環境の場合の情報もご注意ください。)
前提知識
・Db2の基礎的な設計概念
・PowerSystems, AIX のOSアーキテクチャ基礎知識
・AWS EC2やS3, EBSといったサービスの基礎知識
参考資料
以下の資料は全体感を理解するのに役立ちます。
・設計のベストプラクティス
・インスタンスの管理
1.環境差異概要
1.1 コンポーネント対比
オンプレ環境とRDSでは、ユーザが管理すべきレイヤが異なります。
以下は一般的なオンプレ環境とRDSとの比較です。
| オンプレ | AWS RDS for Db2 | |
|---|---|---|
| MW | Db2 | Db2 |
| OS | AIX |
RDS(OS情報非公開) (実機上の表記はx86_64/linux) |
| HW | Power Systems | RDS(HW情報非公開) |
| Storage | SAN Swtich + 外付け(boot+datavg) | EBS |
| NW | L3/L2 NW Switch | AWS NW |
RDS では、OSレイヤー以下はユーザ管理の対象外となります。したがって、以下のような操作は不可(AWSの責務範囲)となります。
・OSログイン、FileSystem管理、ログ収集、OSセキュリティ設計、ハードニング
・上記に付随して、冗長化設計やテスト実施も不要になります。
・障害時の問題判別資料はAWSカスタマーサポートへの依頼を行う必要があるなど、オペレーションの変更点があります。(後述「3.6 障害時保守」)
1.2 アーキテクチャとユーザの管理責任範囲
・AWSとユーザの責任範囲については、以下のページに記載があります。[Amazon EC2 とオンプレミスデプロイの責任の比較]
・アプリケーションの最適化についてはユーザ責務とあります。例えば、SQL文のアクセスプランを見て最適化を行う、必要データベースメモリを構成する、IOPSを最適化する、などのチューニング要素があります。コンポーネントとしてはEBS可用性やインスタンス可用性の基本機能(対障害設計など)はAWSが機能を提供(AWS責務)していますが、サイジングを行ったり要件に合わせた設計を行う点は当然ユーザ責務と考えられます。
・その他(スケーリングや高可用性、データベースバックアップ等)もAWSの範囲になっています。これらは、multiAZ環境でのFO機能や、自動バックアップのしくみなどでAWSから「機能が提供」されています。
・また、EC2と異なりパッチ適用などもAWSの管理範囲となります。とはいえ回帰検証を想定して適応タイミングを事前に計画しておくなどの運用設計はユーザ側で必要になります。
・このように、かなりの範囲でAWS側の「機能」が用意されているものの、実際の要件に即してインテグレーションすること自体はもちろんユーザ責務であるため、要件通りの設計になっているかの統合テスト(性能テスト、障害テストなど)はユーザ側で計画が必要です。(もちろん、RDSが提供するAWS責務の機能の範囲については、ユーザが単体テストのようなことをする必要がないので、かなりの開発コストが抑えられると考えます)
・また一般にクラウドサービスのSLA/SLOはビジネス保証をするものではない点はオンプレ文化との差異として注意が必要な点です。クラウドの場合、計画外停止時間のクレジットキャッシュバックが通常の対応で、万が一の障害やデータ破損を保証するようなサービスではありません。予算次第と思いますが、それも許容できない場合ユーザ責任で２重３重の予防策を講じる他ありません。
1.3 管理インターフェースの違い
上述のように、OSログインをすることがなくなり、代わりにAWSコンソール等を駆使して RDSやDb2の管理を行うことになります。大きく３種類の管理インターフェースがあります。
- 方法1.コンソール(AWS Management Console) / AWS CLI / Amazon RDS API
- 方法2.Db2 ストアドプロシージャ
- 方法3.Db2 コマンド
※細かく挙げると上記以外にも製品SWなどの利用パターンもありますが、操作権限を考慮すると概ね上記の３種に大別できます。詳細は次のセクションをご覧ください。
※方法1は、AWSでの認証(SSO認証、アクセスキー認証、など)が必要です。
※方法2と3は、Db2 connectをするためのDb2のユーザ認証が必要です。(「3.8セキュリティで補足」)
1.3.1 AWS CLI / コンソール(AWS Management Console) /Amazon RDS API
・コンソールやAWS CLI、APIでは、RDSインスタンスそのものの操作(起動停止やバックアップのKick、設定など)を行うことができます。
・以下はコンソールの画面例です。
RDS管理のための基本的なコンソールです。GUI操作での構築・運用で済む場合はこちらの画面にお世話になることと思います。https://console.aws.amazon.com/rds/ にアクセスして該当環境のAWSアカウントにログインします。
・以下はAWS CLIのサンプルです。通常のインターネット接続可能なLinuxやMacのターミナル端末にて、RDS向けのコマンドを実行することができます。AWSに慣れた方であれば説明は不要と思いますが、AWS CLIはあらかじめ作業環境にDL、Installの上、AWS接続先指定や認証のための設定が必要です。
参照ページ:Getting Started
(下画像は、snapshot実行時のコマンド例)
例：Amazon RDS のマルチ AZ DB クラスターのスナップショットの作成
・以下は、Amazon RDS APIの例です。GUIやCLIではなく、app経由での操作など、REST APIで操作を発行することができます。例：CreateDBClusterSnapshot
1.3.2 Db2 ストアドプロシージャ
・ストアードプロシージャは、インスタンス単位より少し細かく、DB単位の管理操作を利用できます。(バッファープール作成、テーブルスペース作成など、一部機能はDDLが利用不可の代わりにストアドプロシージャが提供されます)(「2.1 SQL文」にて詳述)
・利用にはRDSのマスターユーザ(デフォルト名=admin)権限が必要です。
・Db2クライアントをEC2サーバーなどに導入し、RDS上のDb2にリモートでconnectをして操作を発行します。例:表スペース作成
1.3.3 Db2コマンド
・従来のDb2コマンドです。ストアドプロシージャ同様、Db2クライアントからRDS上のDb2にリモートでconnectをして、操作を発行します。DML(SELECT、INSERT等)や、DDL(CREATE TABLEなど)が利用できます。
[例:runstatsコマンド]
2.機能面の考慮事項
ここでは、機能的な制約について具体例とリファレンスを記載します。
2.1 SQL文
RDS for Db2では、一部のDDLやDCLなどが利用できません。代わりに、ストアドプロシージャが提供されます。
・DDL(Data Definition Language)の制約について
スキーマ作成や表作成、キー制約、インデックス、ユーザ定義関数などの多くのSQLについては通常Db2と同様のSQLが実行可能です。一方で制限があるDDLは以下のようなものがあります。
| 制限項目 | 概要 |
|---|---|
| ストレージ・グループ | RDS for Db2ではEBS容量は設定しますが、ストレージ構成やファイルシステム管理のような設計要素はユーザ責務ではないため、ストレージ・グループも設定不可能です。 |
| バッファープール | ストアドプロシージャによる設定が提供されます。 |
| 表スペース | ストアドプロシージャによる設定が提供されます。一部の通常SW版SQLのオプションはストアドプロシージャでは対応していません。 |
| ロール | ストアドプロシージャによる設定が提供されます。 |
※各項目のストアドプロシージャによる設定コマンドは表中のリンクを参照ください。
・ストアドプロシージャのコマンド作法
ストアドプロシージャを実行するには、RDS for Db2 のマスターユーザとして 「RDSADMIN」 データベースにconnectしている必要があります。マスターユーザはRDS for Db2構築時にユーザ側で設定する項目で、デフォルトでは 「admin」 となっています。ストアドプロシージャに関する考慮事項
・ストアドプロシージャ リファレンス
その他の利用可能なストアドプロシージャはこちらから参照できます。
・DCL(Data Control Language)の制約について
権限・特権の付与剥奪、ロールの作成、ユーザ・グループの作成などについても考慮事項があります。
「3.8 セキュリティ」 に記載します。
2.2 監視、性能情報収集
2.2.1 監視機能
・監視機能においては、NW pingやOS ntp監視、PowerHAプロセス監視などのOS以下レイヤーの監視はユーザ責務ではなくなります。代わりに、外形監視、RDSイベント監視が監視要素になります。
・AWSの監視サービス
とはいえ、従来の監視項目のほとんどもAWSで提供される監視サービスでかなりの項目はカバー可能です。「3.6障害時保守」で触れますが、障害時の問題判別やパフォーマンス障害に備えて、ユーザが欲しい情報は取得できるようにしておくことが望ましいです。以下はRDS関連のモニタリングサービスです。(一部はRDS for Db2向けに未対応のサービスです)
| サービス名 | 概要 |
|---|---|
| Amazon RDS 自動モニタリング | |
| Amazon RDS 拡張モニタリング | |
| Performance Insights CloudWatch メトリクス | Db2は未対応 |
| Performance Insights のカウンターメトリクス | Db2は未対応 |
| CloudWatch Database Insights (advanced) | Db2は未対応 |
*デフォルトでは、CloudWatch Database Insights (standard) が利用可能で、自動モニタリングと、(option有効化によって)拡張モニタリングおよびプロセスモニタリングも可能です。
・拡張モニタリングの例
・プロセスモニタリングの例
2.2.2 性能情報収集
・基本的な監視項目については上記のとおり自動モニタリング、拡張モニタリングにて、FOイベントの発生や、OSリソースの監視やCloudWatch、CloudLogsを連携したアラート設定が可能です。また、性能情報の定期的な収集も可能です。
・一方で、Db2のMON_GETで収集可能な、問い合わせ頻度や処理時間の長いSQLの特定など、アプリとの統合テストでの問題判別に有用な情報などは、AWS提供のモニタリングツールが未対応なため、Db2機能で取得する必要がありそうです。
参考：Amazon RDS インスタンスでのメトリクスのモニタリング
2.3 Db2設計、運用コマンド
2.3.1 Db2設計についての考慮事項
主要な設計項目の考慮事項をあげます。
・メモリーサイジング(instance_memory)
DBM構成パラメータの一つ、instance_memoryについては、RDSエンジンでの設計値は90%(ユーザ変更不可)ですが、実機上誤差が生じる可能性があるため、以下コマンドでの確認を推奨します。
(2GiBインスタンスの場合、4K/ページ x 443350ページ ≒ 1.69GiB)
$ db2 "select cast(substr(name,1,24) as varchar(24)) as name, case when value_flags = 'NONE' then '' else value_flags end flags, cast(substr(value,1,64) as varchar(64)) as current_value from sysibmadm.dbmcfg order by name asc with UR" | grep memory
instance_memory 443350
$
・データベース、バッファープール、テーブルスペースのページサイズ
対象ページサイズは 4K, 8K(default), 16K, 32K です。
参考：データベースの管理
・作成DB数の制約
複数DBを作成する場合、DB数に応じてインスタンスメモリを多めに準備する必要があります (下式参照)
Active database limit = (total server memory - 2 GB) / 1 GB
Amazon RDS for Db2 DB インスタンス上の複数のデータベース
2.3.2 Db2運用コマンド
概ねオンプレ相当の機能は利用可能です。ただし、SaaSサービス化したことにより実行方法が変更になるものが多くありますので、その点は既存の運用手順やシェルの 「置き換え」 が必要となります。
・AWS CLI/コンソール/REST APIで実行が必要な機能
インスタンス起動停止、バックアップリストアなど、インスタンス全体に関わる操作
・ストアドプロシージャで実行が必要な機能
DBアクティベート/ディアクティベート、tablespace作成、ユーザ、ロール作成など、DB単位の操作
・Db2 コマンドが引き続き使えるもの
runstats、reorgchk、reorgなどのDB性能に関わる操作
・その他、AWS Premium Support等でのサポートが必要なもの
「3.6障害時保守」にも記載しますが、db2support、db2trcなどはOSに直接アクセスすることができないためAWS Premium Supportへの送付依頼が必要な運用がいくつかあります。
参考：「RDS for Db2 DBインスタンスの管理」
参考：「ストアドプロシージャリファレンス」
3.非機能面の考慮事項
ここでは、非機能的な制約についての具体例とリファレンスについて記載します。
3.1 性能/サイジング
・RDSには以下のようなコンポーネントがあります。1~3についての事前見積もりについては、RDSインスタンス作成、AWS Pricing Calculatorにて作成できます。
・4~7は利用状況に応じての請求項目となります。詳細は備考欄のURLを確認ください。
| # | 項目 | 説明 | 備考 |
|---|---|---|---|
| 1 | RDSインスタンス | CPU、メモリー、Network帯域の組み合わせから最適なインスタンスを選定 | ・Amazon RDS インスタンスタイプ ・DB インスタンスクラスタイプ |
| 2 | データストレージ(EBS) | テーブルスペース、アクティブログ、アーカイブログなどの格納先 プロビジョンドIOPS(io2/io1)または汎用ストレージ(gp3)のいずれかから選択 |
・インスタンスストレージ |
| 3 | IBM Db2ライセンス | Db2ライセンスは必要VPC分あらかじめ準備が必要 | ・「4.1 ライセンス」参照 |
| 4 | バックアップストレージ(S3) | snapshot等配置先 | ・バックアップストレージコスト |
| 5 | プロビジョンドIOPS | 追加のIOPS(スループット) | ・データベースストレージコスト |
| 6 | データ転送 | AZ間の通信やリージョン間通信 | ・データ転送コスト |
| 7 | パブリックIPv4のコスト | インターネットInbout/Outbound通信 | ・パブリックIPv4のコスト |
・表スペースや、バッファープールなど従来のDb2設計要素もありますが、RDSの場合は前述の通りアーキテクチャがAWS独自の仕様で非公開であることも踏まえ、性能テストについてはSTbの統合シナリオテストフェーズを待たず、可能な限り早めにテストを行うことを推奨します。期待値に比べて著しく遅いレスポンスになっていないか、周辺のAWS NWコンポーネント(Direct Connect等を含む)や、Db2詳細設計等で対応可能な範囲なのか、構成を大きく変えたり見積もりに影響がでないか、プロジェクト前に事前のPoCを行うことができれば安心です。
3.2 Db2パラメータ等
・Db2パラメータの多くは、RDSエンジン デフォルト値が推奨となります。
・RDS版 Db2パラメータの仕様について
RDSの設計項目は、Db2デフォルトではなくRDSデフォルトとして変更設定されている項目も多くあります。これらのうち、Db2レジストリー変数、DBM構成パラメータは、コンソールで確認が可能です。
DB構成パラメータについては、コンソールでの確認が不可能なため、別途RDSにdb2 connectして確認が必要です。
・パラメータの中には、先のinstance_memoryや、ファイルキャッシュ利用の有無のように、ユーザ自身で設計が不可能なパラメータも多くあります。特に接続するAppとの兼ね合いで設定しているパラメータなどあれば見直しが必要かもしれません。多くの場合はRDSデフォルトで良いように思いますが、重大度によってはAWS PremiumSupportへの問い合わせを早めに行う必要があります。
・Db2パラメータについての詳細はAmazon RDS for Db2 パラメータを参照ください
3.3 可用性、DR
・Amazon RDS for Db2 でのPowerHA正副構成に近いアーキテクチャは、multi AZ インスタンス構成があります。アベイラビリティゾーン(AZ)を２つ以上利用する構成で、Primaryの正インスタンス上でDb2が稼働し、障害時には異なるAZ環境でSecondary副インスタンスが稼働するという構成です。
・単体のAmazon RDS for Db2 multi AZ インスタンスでの可用性は99.95%、また、EBS自体の可用性は99.99%です。
参考：RDS for Db2 SLA
参考：Amazon Elastic Block Store SLA
ちなみに、RDSの世界でのmulti AZ インスタンスと、multi AZクラスターは名前が似ていますが異なる機能のため、注意が必要です。(multi AZクラスターではリードレプリカという参照系専用のインスタンスを利用します。参照ユースケースが多いシステムの場合はこちらの方が適しているかもしれません。(RDS for Db2でのサポート状況は要確認))
※(2025/9/15追記) Amazon RDS for Db2 がリードレプリカのサポートを開始
リードレプリカ自体はDb2版でもサポートが追加されたそうです。
・Amazon RDS の場合の可用性は、PowerHAの共有disk構成と異なり、EBSデータの正副同期および障害時HA機能により実現されています。理論上、EBS内のアーカイブログとアクティブログが副AZのEBSに瞬時に同期・書き込みされるため、正インスタンスが落ちた場合でも副系でDb2が復帰可能になります。(詳細な技術仕様は非公開情報)
・DR対策としては、バックアップを別リージョンに定期コピーすることが可能です。
バックアップについては「3.5バックアップ&リカバリー」を参照ください
3.4 拡張性
RDSインスタンスは構築後に別のクラスに変更(スケールアップ・ダウン)することが可能です。(ダウンタイムが発生)
また、EBSも拡張が可能です。(こちらはダウンタイム発生なし)なお、EBSは縮小はできません。
参考：RDS ハードウェア仕様
参考：DBインスタンスの設定
参考：DBインスタンスストレージの容量を増加する
3.5 バックアップ&リカバリー
・バックアップ単位
現在のRDS for Db2では、バックアップ(およびリカバリー)の単位はインスタンス単位のみで、複数DBを持つインスタンスを構成している場合でも、単一DB単位でのバックアップ取得やリカバリーはできません。
a.1DB/1インスタンス構成とするか、b.割り切ってインスタンス単位のバックアップで良しとするか(その場合リストアに巻き込まれる他DBが業務的な手順で復旧可能など運用手段があることが前提)、c.運用が複雑になりますが一時的にPITRで別インスタンスにリストアし、データのみexport/loadして復旧する、などの手段が考えられます。
複数DBに対応したのも最近のことなので、DB単位でのバックアップも後追いで発表される可能性も期待したいです。
・バックアップ運用
バックアップは自動バックアップで定期的に設定したメンテナンスウィンドウ内で毎夜取得することも可能ですし、手動バックアップを取得することも可能です。DBバックアップの前後に実行する必要のあるメンテナンスJOBがある場合は、手動バックアップをAWS CLIでキックすることで運用に組み込むことができます。
アクティブログ、アーカイブログはEBSに書き込まれており、EBS自体のsnapshotがS3に取得されます。リカバリー時には、バックアップ一覧から該当バックアップを選択することで復元することが可能です。(新規RDSインスタンスが別名で作成されます)
なお、バックアップ用のS3のエンドポイントにユーザが直接アクセスしオブジェクト操作することはできず、RDSが内部的に管理します。
DRサイト(別リージョン)へsnapshotをコピーすることも可能です。
参考：バックアップの概要
3.6 障害時保守
オンプレSW版では、OSアクセスが可能なため、Db2のログをユーザ自身が取得可能ですが、SaaSのRDSではログ転送はAWS Premium Supportに問い合わせ、取得依頼が必要です。
3.6.1 取得資料
| 資料 | 取得方法 |
|---|---|
| db2diag.log | コンソール、またはCloudWathchLogsからDL可能(要設定) |
| GET DATABASE CONFIGURATION コマンドの実行結果 | Db2管理クライアントからDb2コマンドで取得可能 |
| GET DATABASE MANAGER CONFIGURATION コマンドの実行結果 | Db2管理クライアントからDb2コマンドで取得可能 |
| db2level コマンドの実行結果 | Db2管理クライアントからSQLで取得可能 |
| db2licm -l コマンドの実行結果 | AWS License Managerで確認可能 |
| db2set -all コマンドの実行結果 | Db2管理クライアントからSQLで取得可能 |
| db2support コマンドにより取得されたファイル | AWS Premium Support に問い合わせが必要 |
| First Occurrence Data Capture(FODC) の情報 | AWS Premium Support に問い合わせが必要 |
| コアダンプファイルとライブラリ情報 | AWS Premium Support に問い合わせが必要 |
・参考資料：RDS for Db2 でトラブルシューティングに必要な情報を収集する
3.6.2 サポート体制
実際に何か障害が起こった場合、上記リファレンスの通り、Db2の問題か、それ以外の問題かで、IBMとAWSに問い合わせを行う必要があります。
まずはAWS Premium Supportに問い合わせし、そこでOSやAWS管理のコンポーネントの問題ではないと判断された場合に、IBMサポートへの問い合わせを改めて行う流れになります。(実際の緊急度によっては並行してIBMにも問い合わせするなど、先んじて資料取得依頼をAWS Premium Supportに問合わせしておくのは有効かもしれません)
こういったマルチベンダーサポートの場合、気になるのは問題判別のスピードや、「対策箇所」とするコンポーネントの判断で、ユーザ自身が２社の報告を聞いて総合的に判断するスキルとワークロードを持っている場合は問題ないと思いますが、状況によって「どのように対応するべきか」の判断が必要なケースに、ユーザ自身が対応できることが重要と考えます。実際に障害が起こると、資料収集・状況判断、障害箇所の特定、原因分析、対策検討、など多大な作業を短期間にこなす必要があり、ある程度役割分担やステークホルダーへの連絡体制を組閣しておかなければなりません。
パフォーマンス問題などは、リソースを積んで解決できるような簡単な話なのか、それとも時間的な余裕があればSQLを再構成するのかなど、何を抑えるべきかは開発フェーズの方針にも依存すると考えられます。(クラウドリソースを活用する基本的な考え方は、このような状況ではリソースを増強するのがよくある対応かもしれません。)
いずれにせよ、本番直前になってトラブルがないように、事前PoCや、適宜開発時のパフォーマンス検証までを行い、開発スケジュールに影響が生じない様にトラブル対応バッファを積んでおくのが望ましいと考えます。
また、リリース後に生じる障害時においても、ユーザ側の対応体制、役割分担や段取りは詰めておきたい事項の一つです。オプションとして、AWS社のIncident Detection and Response(Enterprise Supportが必要)を利用したり、Technical Acount Manager (TAM)に障害時の問題判別と統括管理を依頼するなど、ユーザの負担を減らす仕組みが活用できそうです。
・AWS Premium Support
AWSのサポートプランはグレードがあり、より上位のグレードほど、前述のIDRやTAMのサポートが受けられるなどのメリットがあります。
参考資料：AWS サポートプランを比較する
3.7 データ移行
現環境からのデータ以降では、新旧の環境によって利用可能な移行手法が異なります。
- Rehost (OSに変更が無い場合)
Db2のbackup/restoreや、archivelogを用いたrollforwardが利用可能 - Replatfome (OSを変更する場合)
export/load(import)や、データ移行ツールの検討が必要
Replatfomeにおける代表的なデータ移行ツールは以下のようなものがあります。
| ツール | ベンダー | 概要 | 注意点 |
|---|---|---|---|
| export/load(import) | Db2機能 | Db2コマンドによるデータ抽出・読み込み | ・転送容量とメンテナンスウィンドウの制約の考慮 |
| IBM Db2 Bridge | IBM製品 | export/load(import)を拡張した製品 | ・転送容量とメンテナンスウィンドウの制約の考慮 |
| AWS DMS | AWS製品 | AWSの移行サービスを用いた差分同期 | ・データ転送時の本番業務影響の考慮 ・DMSインスタンスとタスク設計 ・シーケンスオブジェクトの複製は不可 |
| IBM CDC レプリケーション | Db2機能 | による差分同期 | ・データ転送時の本番業務影響の考慮 ・CDCインスタンス設計 ・シーケンスオブジェクトの複製は不可 |
| IBM Qレプリケーション | IBM製品 | MQサーバーを用いた差分同期 | ・データ転送時の本番業務影響の考慮 ・MQサーバーの構築、既存環境への設計変更が必要 ・シーケンスオブジェクトの複製は不可 |
上２つは基本的にシステム停止日等での移行を想定(一度に対応できない場合も、論理的な更新フラグなどで差分のみ転送可能なデータ)したもので、一方下３つについては、メンテナンスウィンドウの範囲では対応できないほどのデータ量であるなどexport/load(import)をベースとした手段が利用できない場合に検討が必要になると考えます。各手法では、同期を行う際の本番業務への影響や、移行用中継コンポーネントを作成する場合の設計、既存環境にエージェント等を入れる変更要求が許容されるかなど、考慮点があります。
参考資料：Amazon RDS for Db2 へのデータマイグレーション戦略
3.7.1 AWS DMS
AWS DMSでは移行用の中継インスタンスをAWS上に構築し、CDCレプリケーションを行うことになります。
DMSで移行プロジェクト、ソースデータプロバイダー、ターゲットデータプロバイダーのFQDN、ポート番号等定義を行うことで、テーブルの移行ができます。
DMS上のタスクのイベント通知や監視アラートの機能も提供されています。
なお、AWS DMSの同種データ移行の形式は現時点ではDb2は対応していません。
考慮事項：
- マニュアルにはテーブルが対象とあり、既存環境への権限付与前提にもSYSCAT.SEQUENCESに関する記述がないため、シーケンスオブジェクトなどは移行対象外と想定されます。また、Boolean型が非サポートなど制約があるため、参考資料を参照してください。
参考資料：AWS DMSを使用した Amazon RDS に相当するデータベースへの移行 (同種データ移行
参考資料：IBM Db2 for Linux、Unix、Windows、Amazon RDS データベース (Db2 LUW) を AWS DMS のソースとして使用する
3.7.2 CDC レプリケーション /Qレプリケーション
CDC レプリケーションやQレプリケーションの概要やシステム要件ついては、IBMの参考資料をご覧ください。
CDCレプリケーションではCDCのインスタンスからDb2へのリモートアクセスを利用するため、既存環境への設計変更がありません。
QレプリケーションやSQLレプリケーションでは、オンプレソースDB側に同期転送用の管理テーブルを持つなど、構成によって既存設計変更の考慮が必要な場合があります。
参考資料：System requirements for IBM Data Replication Version 11.4 and IBM InfoSphere Data Replication V11.4
参考資料：CDC Replication Engine For Db2 データベースのシステム要件
参考資料：CDC Replication Engine for Db2 データベース のインスタンスの追加 (UNIX および Linux)
参考資料：RDS for Db2データ移行編 Part3:Qレプリケーションでデータ連携
参考資料：Qレプリケーション・チュートリアル
3.8 セキュリティ
3.8.1 製品ライフサイクル
・バージョン更新
サポート期間については、対応するIBM Db2のEOSまではサポート対象となります。(延長サポート契約がある場合は、延長期日までバージョン保持可能)ただし、オンプレと異なりDb2サポート期間が切れたRDSについては塩漬け対応が不可能なため、バージョンアップ対応が必須になります。期日に関しては、メールやヘルスダッシュボード、契約がある場合はTAMからの連絡が受けられます。
・パッチ適応
重大なセキュリティパッチなど、緊急性が高いものについては適応必須となり、通知が行われます。
ユーザー側でアクションがなされないまま運用された場合、強制適応となる可能性も考慮が必要です。(バージョン更新時も同様)
・fallback
fallbackをする場合、リストア可能なデータはサポート対象のバージョンのバックアップであることが前提となるため、万が一に備えてサポート切れ前に十分な対応期間を設けたバージョンアップ・パッチ適応計画が必要です。
参考資料：Amazon RDS での Db2 のバージョン
参考資料：DB インスタンスのメンテナンス
参考資料：DB インスタンスのエンジンバージョンのアップグレード
3.8.2 権限・特権管理
RDS for Db2の認可機能には制限があります。
| 管理権限 | システム(インスタンス)レベル、またはデータベースレベルでの制御の許可。 一部機能に制約あり |
| 特権 | SELECT、INSERTなど個別のアクションまたはタスクの実行への許可(GRANT 文)。 制約なし |
・管理権限付与の前提となる、各機能コンポーネントでの認証について
システム(インスタンス)レベルでの操作は、RDS for Db2では概ねAWS CLIやコンソール操作で代替されるため、SSO認証やパスキー認証など、AWSの認証を行う必要があります。
データベースレベルでの操作については、「1-3.管理インターフェースの違い」で少し触れましたが、ストアドプロシージャ、Db2コマンドの２種類の方法で操作を行うことになります。ストアドプロシージャについては、RDSを作成した際のマスターユーザーでの認証とDb2接続が必要です。マスターユーザの認証情報は、管理コンソールなどで変更を行うことができます。Db2コマンドについては、権限・特権を持つDb2ユーザ、ロールでの認証が必要です。
・管理権限の制約について
以下は、管理権限のRDSでの利用可否、制約事項の例です。
| 権限 | 制約 | 補足 |
|---|---|---|
| SYSADM(*1) | x利用不可 | SYSADM権限が必要な一部機能(db2pdなど)はストアドプロシージャの提供あり |
| SYSCTRL(*1) | x利用不可 | |
| SYSMAINT(*1) | x利用不可 | |
| SYSMON | ◯ |
| 権限 | 制約 | 補足 |
|---|---|---|
| SECADM(*1) | x利用不可 | |
| ACCESSCTRL(*2) | △ストアドプロシージャで付与可能 |
| 権限 | 制約 | |
|---|---|---|
| DBADM(*2) | △ストアドプロシージャで付与可能 | |
| SQLADM | ◯ | |
| CREATETAB | ◯ | |
| CREATE_EXTERNAL_ROUTINE(*3) | △レジストリ変数の変更が前提 | |
| CREATE_NOT_FENCED_ROUTINE | x利用不可 | not fenced routine自体が利用不可 |
| BINDADD | ◯ | |
| CONNECT | ◯ |
| 権限 | 制約 | |
|---|---|---|
| DATAACCESS(*2) | △ストアドプロシージャで付与可能 |
ストアドプロシージャ利用などの制約事項がない場合(◯となっている従来通りのDCLが利用可能な項目)の Db2 SQLでのGRANT文の作法はGRANT (データベース権限) ステートメントこちらをご覧ください。
*1(抜粋)SYSADM、SYSCTRL、SYSMAINT インスタンスレベルの権限、または SECADM データベースレベルの権限を使用することはできません。
参考情報:Amazon RDS for Db2
*2(抜粋)ロール、ユーザー、またはグループに DBADM、ACCESSCTRL、または DATAACCESS 権限を付与します。
参考情報：rdsadmin.dbadm_grant
*3(抜粋)外部ストアドプロシージャを有効にするには、DB インスタンスに関連付けられているカスタムパラメータグループで、db2_alternate_authz_behaviour パラメータを次のいずれかの値に設定します。
・EXTERNAL_ROUTINE_DBADM — DBADM 権限を持つユーザー、グループ、またはロールに暗黙的に CREATE_EXTERNAL_ROUTINE 権限を付与します。
・EXTERNAL_ROUTINE_DBAUTH — DBADM 権限を持つユーザーが任意のユーザー、グループ、またはロールに CREATE_EXTERNAL_ROUTINE 権限を付与することを許可します。この場合、DBADM 権限を持つユーザーも含め、ユーザー、グループ、またはロールに暗黙的にこの権限が付与されることはありません。
参考資料：Java ベースの外部ストアドプロシージャの設定
*4(抜粋)DB インスタンスを作成するときは、インスタンスの管理者アカウントを指定する必要があります。Amazon RDS は、このローカルデータベース管理者アカウントに DBADM 権限を付与します。
参考情報：管理者アカウント
想定している管理権限が利用できない場合、1.特権の組み合わせに分解できるか、2.もしくはDb2コマンドではなく提供されているAWS CLIやストアドプロシージャでの操作に置き換えすることで想定した運用ができるか検討する必要があります。
また、AWS CLIの認証、マスターユーザの認証(ストアドプロシージャ利用のため)、運用Db2ユーザ(インフラ管理ユーザ、バッチユーザなど)の認証情報の定期メンテナンスはそれぞれで別の対応が必要となります。
マスターユーザのメンテナンスについては、コンソールやCLIを利用するか、AWS Secret Managerを利用したローテーション方法(有償)などがあるようです。
4.その他
4.1 ライセンス
multi AZ インスタンスでの正副構成を想定する場合(cold-standby)、正系のRDSインスタンス仕様(CPU)に合わせたライセンス購入が必要です。(リードレプリカ利用などの場合はライセンスをより多く購入する必要があります)
RDS for Db2上のDb2ライセンスには２種類の形態があります。一つはBringYourOwnLicense (BYOL)、もう一つはAWSマーケットプレイスで購入する方法です。
-
BYOL:
IBMから購入済みのライセンスの持ち込みとなります。あらかじめ、RDSオーダー前にIBMカスタマーIDとサイトIDをRDS構築用のパラメータグループに登録する必要があります。
また、AWS License Managerにてライセンスを検出する設定を行います。(こちらはRDSのオーダープロセス内での管理名の指定で設定が完了します) -
AWSマーケットプレイス：
あらかじめAWSマーケットプレイスで購入が必要です。こちらの場合、時間単位で購入が可能となります。
(抜粋)
Bring-Your-Own-License (BYOL) モデルでは、まず IBM Customer IDと IBM Site ID を含むカスタムパラメータグループを作成する必要があります。詳細については、「Db2 の Bring Your Own License」を参照してください。
AWS Marketplace 経由の Db2 ライセンスモデルでは、使用する特定の IBM Db2 エディションの有効な AWS Marketplace サブスクリプションが必要です。まだお持ちでない場合は、使用する IBM Db2 エディションの Db2 サブスクリプションを AWS Marketplace で購入する必要があります。詳細については、「AWS Marketplace 経由の Db2 ライセンス」を参照してください。
参考資料：Amazon RDS for Db2 DB インスタンス作成の前提条件
ここまでご覧いただきありがとうございました。
ご参考になれば幸いです。