■初めに

マネージドサービスの特性により、従来の基盤開発・導入とは異なる品質向上のアプローチが求められる。

近年、AWSをはじめとしたマネージドサービスの活用が進む中で、「内部挙動が見えない」「期待通りに動作しているか判断しづらい」といった課題に直面したエンジニアの方も多いのではないだろうか。特に、採用実績が少ない/実績がない製品を初めて導入する場面では、不確実性の高さが品質確保の難易度をさらに引き上げる。
こうした背景を踏まえ、本記事では、新規製品導入時における「品質向上の取り組み」について整理する。我々の実プロジェクトにおいてAWS DMSを導入した際の事例をベースに、どのような観点でリスクを捉え、どのように対処していったかを体系的に示す。
特に、マネージドサービス特有のブラックボックス性を前提としながら、どのようにリスクを可視化し、品質を向上していくかに焦点を当てて解説する。

■AWS DMSとは(製品概要)

AWS DMS（Database Migration Service）は、データベース間の移行および継続的なデータレプリケーションを実現するフルマネージドサービスである。
オンプレミスからクラウドへの移行や、異種DB間のデータ連携、分析基盤へのデータ転送など、幅広い用途で利用される。
代表的なレプリケーション方式は以下の通り。
・Full Load：既存データの一括コピー
・CDC（Change Data Capture）：差分データの継続同期
・Full Load + CDC：初期ロード後に差分同期

参考:
AWS DMSとは
AWS Database Migration Service とは? – AWS データベース移行サービス
ソースDB
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Sources.html#CHAP_Introduction.Sources.title)
ターゲットDB
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Targets.html

■今回の構成と前提

実際のPJでは以下の構成でデータレプリケーション基盤を構築した。
使用サービス
AWS DMS サーバレス
ソース Oracle DB (オンプレミス環境)
ターゲット Amazon S3

■品質向上のために実施した検証と対応

新規製品導入時においては、「何が分からないか」を明確化することが品質向上の出発点となる。特にマネージドサービスでは、内部挙動の不可視性により、機能・非機能の双方で想定外の制約や挙動に直面する可能性が高い。
そのため本PJでは、事前に機能要件・非機能要件を定義した上で、問題となりやすい領域にあたりをつけ、検証観点を整理しPoCを実施した。以下に代表的な検証事例を示す。

■検証事例

PJ内では以下事例を例にし、検証を行った。

 
観点 事例①：自動スケール挙動 事例②：Oracleソース利用時の制約
検証の目的・背景 Serverless化によるコスト最適化と運用簡略化を実現するため、DCUの自動スケール挙動を把握する Oracleソース利用時の制約が業務要件に影響しないかを確認する
公式情報 DCUはMaxCapacityUtilization（メモリ）およびCPUUtilizationによりスケール 「30バイト以上のオブジェクト名は非サポート」と記載あり
問題提起 スケール条件の詳細が不透明であり、期待通りにスケールしない可能性 制約がどの粒度（テーブル／カラム）でどのような影響を及ぼすか不明
マネージド製品特有の制約
（観測不可）		 CPUUtilizationがユーザーから観測不可のため、スケール発生条件を正確に把握できない 内部処理仕様が非公開のため、制約発生時の具体的な挙動が事前に把握できない
検証方法 複数パターンのデータ量・負荷条件でレプリケーションPoCを実施し、DCUの挙動を観測 長いカラム名を含むテーブルを用いてフルロード／CDCそれぞれでPoCを実施し、挙動差分を確認
検証結果 メモリ使用率が低くてもスケールしないケースがあり、性能が安定しない事象を確認 CDCタスクにおいて、更新対象外カラムがnullで連携される不具合を確認（フルロードでは未発生）

上記から①については連携時間のための性能を優先するために、自動スケールは行わないこととし、DCU値は固定値とした。
しかしserverlessではDMSの設定等以外のリソースを管理する必要はないため、今回はプロビジョンド型ではなくserverlessを採用した。
②については
今回OracleをソースとしたCDCを行うにはDMSの仕様上に考慮事項があったものの、DMSに機能面/運用面の優位性があり、考慮事項を事前検証によって確認する条件で合意形成を行い、DMSを採用した。

■品質向上のために必要なプロセス

前項の内容を抽象化すると、新しい製品を導入する際の品質向上には、設計確定までの段階において以下のプロセスが必要となる。

フェーズ 目的（なぜ必要か） 実施内容 チェックすべきポイント 得られること
① 前提・リスクの明確化（検証設計） ブラックボックス性により不確実性が高いため、検証すべき領域を特定する 公式ドキュメント、サポート情報をもとにリスク仮説を整理し、「検証が必要な前提」を定義 ・性能に影響する要因（CPU／メモリ／NW）・仕様上の制約・挙動が不確実な領域（例：自動スケール） 検証観点が明確化され、PoCの網羅性と効率が確保される
② 検証（PoC）による挙動の把握 仕様ではなく実挙動ベースで製品理解を行うため 洗い出した観点に対してPoCを実施し、条件を変えながら挙動を確認 ・実データ／実運用に近い条件か
・負荷やデータ量のバリエーションを持たせているか
・結果に再現性があるか		 ブラックボックス領域の実挙動が可視化され、リスクの実態が把握できる
③ 設計へのフィードバック（意思決定） 不確実性を排除し、安定したシステム設計を実現するため PoC結果を前提に設計方針を見直し、必要に応じて構成・方式を変更 ・理想ではなく実測結果に基づいているか
・再現性のある挙動を前提にしているか
・要件（性能・機能）を満たしているか		 実挙動に即した現実的な設計が確定し、品質リスクが低減される

重要なのは、「公式の仕様を踏まえつつ、実機検証による実挙動を基準に設計する」というスタンスである。
例えば、
・自動スケールが期待通りに動作しない場合は、スケールに依存しない構成（DCU固定）を採用する
・CDCで仕様制約に抵触する場合は、前提を見直しFull Load中心の構成に変更する
・制約を受けてでも採用する必要の有無を検討する
といったように、検証結果をもとに設計を現実解へ寄せることで、不確実性を排除し品質を向上することが可能となる。

このプロセスを踏むことで、マネージドサービス特有のブラックボックス性を前提としながらも、再現性のある品質向上が実現できる。

■まとめ

AWS DMSは強力かつ容易に導入可能なサービスである一方で、マネージドサービス特有のブラックボックス性により、内部挙動の把握が難しく、仕様を元に設計しただけでは品質を向上できないケースがあることが実プロジェクトを通じて明らかになった。
このような前提においては、
仕様やドキュメントを前提に設計するのではなくだけではなく、検証によって挙動を把握し、その結果に基づいて設計する
というアプローチが重要となる。
本記事で整理した通り、新しい製品導入時の品質向上には、
① 前提・リスクの明確化（検証設計）
② 検証（PoC）による挙動の把握
③ 設計へのフィードバック（意思決定）

といったプロセスを踏むことが不可欠である。
これらのプロセスを通じて、製品仕様に依存した設計ではなく、実際の挙動に基づいた設計を行うことで、不確実性を排除し、品質を向上させることが可能となる。
新しい製品を採用する際には、その利便性だけでなく、こうした品質向上のためのプロセスを前提とした設計・検証を行うことが重要である。

※記載されている会社名、 商品名、またはサービス名は、各社の登録商標または商標です。

記事に関するお問い合わせ