Dutchieとはどのようなプラットフォームか
Dutchieは、大麻産業向けに特化した統合テクノロジープラットフォームです。米国やカナダをはじめ大麻が合法化された地域において、6,500以上の事業者（ディスペンサリー）に対してeコマース・POS・決済機能を単一システムで提供しています。年間の取引量は220億ドルを超え、月間数百万件のeコマース取引を処理する、非常に高いトラフィックとデータ量に日々対応するプラットフォームです。
Dutchieが特に重視するのが、年間最大の販売期間とも呼ばれる「4/20週」です。4月20日は大麻文化において重要な記念日とされており、この期間にはディスペンサリーがブラックフライデー並みのトラフィックを経験します。オンライン注文・在庫管理・コンプライアンス追跡・POS業務のすべてをDutchieのインフラに依存するディスペンサリーにとって、この期間中のシステム安定性は死活問題です。
こうした要求の厳しい環境を支えるため、DutchieはAzure SQL Managed InstanceからAmazon RDS for SQL Serverへの戦略的な移行を推進しました。この移行は単なるプラットフォーム変更ではなく、動的スケーリング・パフォーマンス最適化・コスト効率・将来の成長基盤構築を同時に達成する、包括的なアーキテクチャ刷新プロジェクトでした。
移行前のボトルネック — Azure SQL Managed Instanceの限界
Dutchieが抱えていた最大の課題は、Azure SQL Managed Instanceのアーキテクチャ的制約にありました。コンピュートとストレージが一体化したSKU構成は管理の簡素化には役立ちますが、Dutchieのような変動の激しいワークロードには対応が困難でした。
まず挙げられるのが、IOPS制約によるパフォーマンス劣化です。データベースアクティビティが急増するピーク時に、IOPSがプラットフォームの制限に達し、クエリパフォーマンスが著しく低下しました。4/20週のような高トラフィックイベント時に、ディスペンサリーのリアルタイム体験に直接影響を与える深刻な問題でした。
次に、インスタンスタイプのコアとメモリの比率が固定されており、実際のワークロード特性に合わせた最適なサイジングが困難でした。その結果、コストと性能の両面で非効率な状態が続いていました。Dutchieのようなメモリ集約型ワークロードにとって、この制約は特に大きな足かせとなっていました。
さらに、高スループットワークロードの最適化に有効なIn-Memory OLTPのメタデータ操作など、SQL Serverの重要機能がAzure SQL Managed Instanceでは十分にサポートされていませんでした。機能的な制約がそのまま開発・運用上の制約として積み重なり、エンジニアリングチームはこれらの制約を回避するためのアプリケーションレベルの独自実装を開発・維持し続けなければなりませんでした。この技術的負債は、チームのリリース速度を著しく低下させ、本来の機能開発に投資すべきリソースを圧迫し続けていました。
Amazon RDS for SQL Serverへの移行アプローチ
Dutchieの移行は、自動化・安全性・顧客への影響最小化を軸に、段階的かつ慎重に設計されました。
移行先として選定されたのはRDS上のx2iednインスタンスファミリーです。高コア対メモリ比率とtempdb用ローカルNVMeストレージを提供し、メモリ集約的で書き込み負荷の高いDutchieのワークロードに最適なインスタンスです。DutchieのスタッフDBREエンジニアであるKendra Little氏は、「Amazon RDS for SQL Serverは、高可用性とパフォーマンスを維持しながら、コンピュート・ストレージ・レプリカを独立してスケールする柔軟性を提供します。x2iednインスタンスを使用することで、トラフィック急増を容易に処理し、ユーザーに一貫して信頼性の高い体験を提供できます」と述べています。
技術的な改善として特に重要なのが、RCSI（Read Committed Snapshot Isolation）の有効化です。RCSIは行バージョニングを使用した楽観的同時実行モデルを提供し、リーダーとライターの間のブロッキングを大幅に削減します。また、将来的なMVCC対応データストアへの移行を見据えたコードベースの整備にも寄与しています。
移行プロセス全体はAWS CLIを活用したPythonスクリプトで自動化されました。本番規模のデータセットを使用して複数回のリハーサルを実施し、2時間のメンテナンス時間内でデータ損失ゼロのカットオーバーを達成しています。また、HammerDBを使った徹底的なベンチマークをカットオーバー前に実施し、移行後のメトリクスとの比較で改善を定量的に検証しました。RPO/RTOをすべての障害シナリオにわたってマッピングし、アーキテクチャ決定の指針として活用しています。
さらに、DBデプロイメントをAzure DevOpsからGitHub Actionsに移行したことで、リリースパイプラインの高速化と信頼性向上を同時に実現しました。インフラとアプリケーションの変更管理が一元化され、開発チームの生産性も大幅に向上しています。
移行後に得られたブレークスルー — パフォーマンスとビジネス成果
Amazon RDS for SQL Serverへの移行は、技術・ビジネス両面に大きなブレークスルーをもたらしました。
パフォーマンス面では、I/Oレイテンシの減少・キャッシュ効率の改善・高同時実行ワークロードでのブロッキング削減が実現されました。x2iednインスタンスにより大量のデータページを長期間メモリに保持できるようになり、繰り返しアクセスされる頻度の高いデータへのアクセスがキャッシュ上で完結するケースが大幅に増加しています。RCSIの実装により、高同時実行ワークロード全体でのリーダーとライター間のブロッキングが削減され、ピーク時のパフォーマンス劣化が大幅に抑制されました。
スケーリングの観点では、IOPSとコンピュートリソースを独立してスケールできるようになったことが特に重要です。以前はAzure SQL MIのSKU構成が変動するワークロードパターンに対応できず、性能不足とコスト過剰が同時に発生していました。Amazon RDS for SQL Serverへの移行後は、ワークロードに応じた柔軟なスケーリングが可能となり、オーバープロビジョニングを避けながらピーク時の需要に効果的に対応できています。その結果、運用効率とコスト管理が大幅に改善されました。
最も注目すべき成果は、2025年の4/20週において、システムが史上最高のトラフィックが持続した中でも完全な安定性を維持したことです。ブラックフライデー並みのトラフィックがディスペンサリーに集中するこの重要な期間を、高速かつレスポンシブな状態で乗り越えました。これは移行前の課題を根本から解決した証左といえます。
エンドユーザー体験においても、移行前と比較してよりスムーズなチェックイン・より高速なカート更新・より迅速なチェックアウトが実現されています。大規模データセットやバッチ変更操作での信頼性も向上しました。運用面では、ワークロードの効果的なセグメント化によりデプロイメントや分析ジョブ実行中のリスクが軽減され、RDS for SQL Serverのインスタンス名前変更機能によりメンテナンスやインシデント対応時の環境管理も容易になっています。
成功する移行のためのベストプラクティス
Dutchieの事例から、データベース移行を成功させるための重要な要素が明らかになりました。これらは特定のクラウドベンダーやデータベースエンジンに依存しない、普遍的なベストプラクティスとして参考にできます。
第一に、早期のパフォーマンスベースライン確立が欠かせません。移行前にHammerDBのような負荷テストツールで現行環境の性能を定量化しておくことで、移行後の改善を客観的に測定できます。また、すべての障害シナリオに対してRPO（目標復旧時点）とRTO（目標復旧時間）を事前にマッピングすることで、アーキテクチャ決定の根拠が明確になります。
第二に、本番規模でのリハーサルが重要です。Dutchieは実際の本番データセットを使用して複数回のリハーサルを実施することで、本番カットオーバー時の不確実性を最小化しました。このアプローチにより、2時間という短いメンテナンス時間内でデータ損失ゼロのカットオーバーを実現しています。
第三に、移行プロセス全体の自動化への投資が長期的なリターンをもたらします。手動作業を最小化することで、ヒューマンエラーのリスクを低減し、再現性の高い移行プロセスを確立できます。Dutchieの場合、AWS CLIとPythonを組み合わせることで、複雑な移行ワークフローを信頼性高く実行しました。
第四に、クラウドベンダーとの密接な連携を活用することです。AWSのソリューションアーキテクトやテクニカルアカウントマネージャーとの協力により、Dutchieはx2iednインスタンスの選定やRCSI実装など、最適なアーキテクチャを迅速に決定することができました。
RagateのAWSデータベース移行支援
Ragateは、AWSを中心としたクラウドネイティブ移行支援の専門企業です。AWS Foundational Technical Review（FTR）認定を取得し、代表の益子竜与志はAWS Top Engineers 2024（Service部門）を受賞しています。「7Rフレームワーク」を活用した移行戦略の策定から、自動化スクリプト開発・インスタンスサイジング・マルチAZおよびリードレプリカ設計・本番カットオーバーまで、一気通貫でご支援します。
Dutchieの事例のように、オンプレミスや他クラウドからAmazon RDS for SQL Serverへの移行には、インスタンスタイプの選定・RCSI等の並行処理設定・自動化パイプラインの構築など、多くの技術的判断が求められます。Ragateでは過去の移行実績とAWSの最新ベストプラクティスをもとに、お客様のワークロード特性に合わせた最適なアーキテクチャ設計と移行計画をご提案します。
また、代表・益子竜与志の著書『AI駆動で進める「小さく確実な」クラウドネイティブ移行』（技術評論社、2026年3月発売）では、7Rフレームワーク・Dify×Amazon Bedrockの活用・AIOps実践ガイドなど、クラウド移行の実践的知識が全512ページで詳述されています。自社でクラウド移行を推進したいエンジニアにとっても参考になる内容です。
Azure SQL MIからAmazon RDS for SQL Serverへの移行、またはオンプレミスのSQL ServerからAWSへの移行をご検討の方は、ぜひRagateにご相談ください。お客様の状況に合わせた最適なアプローチをご提案します。
