ボトルネックからブレークスルーへ：Dutchie のデータベース移行の軌跡

本記事は 2026 年 3 月 9 日 に公開された “From bottlenecks to breakthroughs: Dutchie’s database migration journey” を翻訳したものです。

Dutchie は大麻業界向け (米国やカナダなどでは合法化されています) の統合テクノロジープラットフォームで、小売業者やブランドがより多くの大麻をより迅速かつ高い利益率で販売できるよう支援しています。6,500 を超える大麻事業者が Dutchie を利用しており、年間 220 億ドルの取引量と月間数百万件の e コマース取引を支える重要な業務を担っています。顧客は特に業界最大の売上期間である 4/20 週 (ディスペンサリー (大麻の合法的な販売店) がブラックフライデー並みのトラフィックを経験する時期) において、システムの信頼性を重視しています。ディスペンサリーはオンライン注文や在庫管理からコンプライアンス追跡、POS 業務まで、あらゆる業務を Dutchie のインフラに依存しているため、この重要な販売期間中にピークパフォーマンスを維持することが極めて重要となります。

Dutchie は、これらの要求の厳しいワークロードに対応するため、戦略的なデータベース変革イニシアチブを通じてデータベースインフラストラクチャを変革しました。Azure SQL Managed Instance から Amazon Relational Database Service (Amazon RDS) for SQL Server への移行を推進したいくつかの重要な目標は、予測困難なトラフィック急増に対応するインフラの動的スケーリング機能の確保、大量の同時ユーザー負荷に対するデータベースパフォーマンスの最適化、信頼性を維持しながらの運用コスト削減、将来の成長とモダナイゼーションに向けた基盤構築です。全国のディスペンサリーにとって、このピーク期間中のシステムパフォーマンスは、年間で売上が最も集中する週の一つにおいて顧客にサービスを提供する能力に直接影響を与えます。

この投稿では、Dutchie が 2025 年の 4/20 週に向けて、ミッションクリティカルなワークロードを Amazon RDS for SQL Server に移行する際の課題をいかに成功裏に乗り越えたのかを探ります。

課題背景

Dutchie が急速に拡大する顧客基盤にサービスを提供するために規模を拡大するにつれて、データベースアーキテクチャもそのペースに追いつく必要がありました。複雑なプラットフォーム全体でリアルタイムの大量トランザクションをサポートするには、スピード、回復力、そしてプレッシャー下での一貫したパフォーマンスを実現する基盤が必要でした。

アプリケーションについて

Dutchie は、大麻事業者向けに特別に設計された統合プラットフォームを提供し、e コマース、POS、決済を単一の連携したシステムに統合しています。このシステムにより、ディスペンサリーは業務を効率化し、収益成長を促進し、店舗とオンラインの両方でモダンでパーソナライズされた小売体験の提供を支援します。

Dutchie は、規制遵守、動的プロモーション、ロイヤルティプログラム、店舗カスタマイズなど、複雑な業界特有の課題に対応します。Dutchie のアーキテクチャは、全販売チャネルで高速かつ信頼性の高い取引を維持しながら業務を効率化します。リアルタイムカート同期、カーブサイドピックアップ機能、包括的な API 統合などの高度な機能により、ディスペンサリーはパフォーマンスやコンプライアンスを損なうことなく、迅速な対応力を維持できます。

技術的な要求仕様

Dutchie のデータベース移行戦略は、速度、安全性、拡張性、一貫したパフォーマンスという 4 つの重要な目標に焦点を当てていました。

• 高速でデータ損失ゼロの移行 : システムは最小限のダウンタイムでデータ損失ゼロの移行が求められていました。この環境では、切り替えを 2 時間のメンテナンス時間内に完了する必要がありました。移行プロセスは、移行期間中もシステムの可用性を維持しながら、運用コンポーネント全体で完全なデータ整合性を確保する必要がありました。
• オーバープロビジョニングなしでのストレージパフォーマンス向上 : コンピュートリソースの過剰プロビジョニングなしでのストレージパフォーマンス最適化が、新しいアーキテクチャにとって不可欠でした。ソリューションには、効率的なコア対メモリ比率を持つインスタンスタイプと、スループットとレイテンシが改善されたストレージが必要でした。この構成は、コンピュート容量を実際のワークロード需要と正確にバランスさせ、リソースの過剰割り当てを排除しながら、ピーク時の最適なパフォーマンスを実現することを目的としていました。アーキテクチャはまた、特に高トラフィックイベント中に、応答性や信頼性を損なうことなく、変動するトランザクション量に対応するため、ダウンタイムなしでの動的スケーリングをサポートする必要がありました。
• 回復力のあるバックアップとフェイルオーバー戦略 : システムは、マルチ AZ 冗長性とウォームフェイルオーバーインフラの戦略的活用を通じて、事業継続性を考慮した設計が必要でした。バックエンドアーキテクチャ内の自動フェイルオーバー機能は、長期的なスケーラビリティに必要な俊敏性を維持しながら、復旧時間目標を満たす必要がありました。
• スケーラブルなアーキテクチャ : アーキテクチャは、サービス中断なしに事業成長をサポートするために水平方向にスケールする必要がありました。システムは、既存のソリューションを再設計することなく、複数の市場にわたる新しいディスペンサリーのオンボーディングとエンドユーザートラフィックの増加に対応する必要がありました。

ピーク対応パフォーマンス：システムは、トラフィックが集中するイベント時でも、高速かつ応答性の高い状態を維持する必要がありました。新しいアーキテクチャは、ピークトラフィック時でも、チェックアウト、検索、POS 処理全体で持続的な低レイテンシパフォーマンスを提供する必要がありました。

これらの優先事項が Dutchie の移行戦略を導き、RDS for SQL Server が長期的なスケーラビリティに必要な柔軟性、パフォーマンス、コスト効率を提供することを確認しました。

移行前の課題

Dutchie の Azure SQL Managed Instance 上の従来のインフラは、パフォーマンスと信頼性の目標に影響を与える深刻なスケーリング課題を抱えていました。コンピュートとストレージが一体化した Azure SQL Managed Instance SKU の事前定義された構成は、変動するワークロードパターンに対処するには不適切であることが判明しました。Dutchie のプラットフォームには、データベースアクティビティの急激な増加時に IOPS を制約するリソース制限があり、非効率なコア対メモリ比率により、コストパフォーマンスを最適化するためのインスタンスの適切なサイジングが困難でした。これは、ディスペンサリーとその顧客のリアルタイム体験に直接影響を与えました。Azure SQL Managed Instance での In-Memory OLTP メタデータ操作などの重要な機能のサポート不足により、高スループットワークロードを最適化する能力が制限されました。これらの制約により、アプリケーションレベルの回避策を開発するために膨大なエンジニアリングリソースが必要となりました。この追加の複雑さは、リリース速度を遅らせるだけでなく、スケーリングの取り組みも困難にしました。トランザクション量が増加し、トラフィックパターンがより多様化するにつれて、Dutchie のプラットフォームには、拡大するビジネス要件をサポートするために、より柔軟で堅牢なデータベースインフラが必要であることが明らかになりました。

解決策

目標を達成するため、Dutchie は柔軟性、パフォーマンス、水平スケーラビリティに重点を置いたシステム全体のバックエンドアーキテクチャを設計しました。Dutchie のマルチセル展開モデルでは、各本番セルが独自の名前空間と専用の Web API サービスを持って独立して動作します。データベースレベルでは、マルチ AZ とリードレプリカの両方を活用し、回復力を提供し、ワークロードを分離し、サービス間の競合を発生させることなく水平にスケールします。また、高トラフィック期間中のトラフィックとリソース割り当てに対するきめ細かい制御も可能にします。

これらの同じ原則は、データベースアーキテクチャの指針にもなりました。Dutchie には、個々のワークロードを独立してスケールし、パフォーマンスの分離を提供し、需要の急増に迅速に対応する能力が必要でした。データベースインフラはこのモデルを反映し、全体的なバックエンド戦略と整合する水平スケーラビリティと柔軟な負荷分散を提供しました。

Dutchie のプラットフォームは、本番環境、ユーザー受け入れテスト (UAT)、ステージング、開発を含む環境階層全体で、シングルテナントとマルチテナントの両方のデプロイメント構成をサポートしています。このアーキテクチャにより、大規模での一貫したパフォーマンスを維持しながら、エンタープライズ顧客や複数店舗運営者のニーズに応える制御力と俊敏性を得ています。

データベースインフラストラクチャ

Dutchie はスケーリングとオペレーションをより制御するために、アプリケーションデータベースを RDS for SQL Server に移行しました。

Dutchie のスタッフ データベースリライアビリティエンジニア、Kendra Little は次のように述べています。

「Amazon RDS for SQL Server は、高可用性とパフォーマンスを維持しながら、コンピュート、ストレージ、レプリカを独立してスケールする柔軟性を提供します。メモリ集約的で書き込み負荷の高いワークロードに対して x2iedn インスタンスを使用することで、トラフィック急増を容易に処理し、ユーザーに一貫して信頼性の高い体験を提供できます。負荷を分散するための様々なオプションがあり、RDS がプロビジョニングを処理するため管理が簡単です。」

パフォーマンス重視のワークロードにおいて、x2iedn インスタンスファミリーは高いコア対メモリ比率と tempdb 用のローカル NVMe ストレージを提供し、過度なオーバープロビジョニングなしにスループットと応答性を大幅に向上させます。

移行戦略

自動化、安全性、顧客への影響の最小化に重点を置いて、慎重に計画された段階的なアプローチで移行に取り組みました。主要なステップには以下が含まれていました：

• Read Committed Snapshot Isolation (RCSI)の有効化 : SQL Server における RCSI は、デフォルトの READ COMMITTED アイソレーションレベルの動作を変更するデータベースオプションです。行バージョニングを使用してより楽観的な同時実行モデルを提供し、リーダーとライター間のブロッキングを削減します。これにより、高トラフィックワークロード下でのブロッキングを防ぎ、ダウンストリームデータストアとの移行後のデータ同期を改善しました。また、Dutchie のアプリケーションがアイソレーションとロッキングを処理する方法をモダナイゼーションし、マルチバージョン同時実行制御 (MVCC) に依存する Amazon Aurora PostgreSQL-Compatible Edition などの将来のデータストアに対してコードベースをより適応しやすくしました。
• バックアップと復元プロセスの自動化 : AWS Command Line Interface (AWS CLI) を使用して Python スクリプトを構築・改良し、移行ワークフローを完全に自動化しました。これらのスクリプトは重要なデータベース設定を検証し、環境間で一貫した設定を提供し、フルサイズのデータセットでプロセスをリハーサルし検証することを可能にしました。
• 移行前後のパフォーマンス測定 : カットオーバー前に詳細な監視ベースラインを確立し、主要なワークロード全体でパフォーマンスの改善を検証するために、移行後のメトリクスと比較しました。
• デプロイメント自動化の改善 : データベースコードのデプロイメントを Azure DevOps から GitHub Actions に移行し、より高速で信頼性の高いリリースパイプラインを実現しました。

結果とメリット

RDS for SQL Server への移行により、パフォーマンスの向上、運用オーバーヘッドの削減が実現され、システムの管理とスケーリングにおいてより大きな柔軟性を得ることができました。

パフォーマンス改善

移行後、Dutchie は重要なすべての分野で測定可能な向上を実現しました。データベース操作全体で大幅なパフォーマンス改善を達成しました。同社の I/O レイテンシが減少し、データ集約的な操作のパフォーマンスが向上しました。キャッシュ効率が改善され、より多くのデータページをより長期間メモリに保持できるようになりました。RCSI の実装により、高同時実行ワークロード全体でブロッキングを削減しました。同社は GitHub Actions を使用してデータベースデプロイメントプロセスを合理化し、より高速で信頼性の高いデプロイメントを実現しました。

IOPS とコンピュートリソースを独立して調整できるようにスケーリング機能を改良しました。これによりスケーリングの柔軟性が向上し、オーバープロビジョニングを避けながら、ピーク時のパフォーマンス要求に効果的に対応できるようになりました。その結果、運用効率とコスト管理が改善されました。

「Azure SQL Managed Instance から Amazon RDS for SQL Server への移行により、最も要求の厳しいワークロードに必要な精密な制御とスケーラビリティを得ることができました。4/20 の週には、ブラックフライデー並みのトラフィックがディスペンサリーに集中しますが、史上最も高いトラフィックが持続した週においても、我々のシステムは安定性を確保することができました。システムはイベント全体を通して高速かつレスポンシブな状態を維持しました。RDS for SQL Server の柔軟性と信頼性は、年間でも最も売上が集中する時期に数千のディスペンサリーをサポートする上で不可欠であることが証明されました。」

ビジネスインパクト

販売業者と小売業者は、移行前の体験と比較して、よりスムーズなチェックイン、より高速なカート更新、より迅速なチェックアウトを体験しました。Dutchie の信頼性は全体的に向上し、特に大規模なデータセットやバッチ変更を含む操作において顕著でした。

運用面では、ワークロードをより効果的にセグメント化できるようになり、デプロイメントや分析ジョブ中のリスクを軽減しています。RDS for SQL Server では、インスタンスの名前変更も可能で、この機能によりメンテナンスが簡素化され、インシデントや変更時の環境管理がより簡単になります。

より柔軟なスケーリングオプションと併せて、これらの改善により、Dutchie は進化し成長する業界をサポートするために必要な運用上の俊敏性を得ることができます。

ベストプラクティスと学び

成功するマイグレーションは、信頼性の高いデータ、明確な復旧目標、そして再現可能なプロセスという入念な事前準備・構築することから始まります。

この移行により、Dutchie にとっていくつかの重要な洞察が明らかになりました。早期にパフォーマンスのベースラインを確立し、HammerDB などのツールを使用して徹底的なベンチマークを実施することは、進捗を測定し最適化を検証するために不可欠であることが証明されました。チームはまた、潜在的な障害シナリオ全体にわたって目標復旧時点 (RPO) と目標復旧時間 (RTO) をマッピングし、それらの目標を使用してアーキテクチャの決定を導くことが重要であることを発見しました。データを取り残すことなく、同時にツールの簡潔性、回復力、明確性を最適化する移行方法を選択することで、実行の効率化に役立ちました。

Dutchie にとって、自動化は移行において中心的な役割を果たし、本番規模のデータセットを使用して複数回のリハーサルを完了することで、チームが自信を持って移行できるよう支援しました。バックアップとリストアを使用する際、Dutchie にとってはダウンタイムを削減し、カットオーバー時の信頼性を向上させるために、最大スループットが得られるようワークロードを調整することが重要でした。最後に、Dutchie は AWS と密接に連携してインスタンスを効果的に適正サイズ化し、パフォーマンスとコストを最適化する際の適切なバランスの実現に役立ちました。

これらのベストプラクティスにより、Dutchie はリスクを軽減し、より迅速に行動し、最も重要な部分にエンジニアリング時間を集中させることができました。

結論

Amazon RDS for SQL Server への移行により、Azure SQL Managed Instance で直面していたスケーリングとパフォーマンスの制限を突破することができました。自動化、ベンチマーク、アーキテクチャの柔軟性への投資により、運用オーバーヘッドを削減し、顧客体験を向上させ、持続可能な成長のための基盤を構築しました。

この移行は、同社のシステムを支えるインフラへの戦略的投資でした。Dutchie が急速に変化し、高度に規制された業界で事業を展開する調剤薬局にサービスを提供し続ける中、信頼性の高いパフォーマンスと迅速なスケーリング能力の提供は、お客様をサポートし、その成長を支援する方法の基盤となっています。

ピーク時に同様のデータベーススケーリングの課題に直面している企業は、Dutchie の経験を参考にすることができます。移行を検討しているお客様は、成功的な実装を支援するために概念実証を実行すべきであることは言及に値します。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

著者について

このブログ投稿への貴重な貢献をしてくれた Rachel Stearns 氏に感謝します。