Auto Trader: Oracle から PostgreSQL への道のり

※この投稿は米国時間 2021 年 3 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

編集者注: 今回は、英国最大の自動車のオンライン マーケットプレイスである Auto Trader にお話を伺います。Auto Trader は、英国での自動車の買い取り、販売プロセスを改善し、消費者が小売店やメーカーとつながるためのプラットフォームを提供している企業です。同社がオンプレミスからクラウドにデータベースを移行する過程で Google の Cloud SQL をどのように使用したかをご紹介します。

Auto Trader の DNA にはイノベーションが組み込まれていると言っても過言ではありません。当社は、お客様とともにビジネス ソリューションを成長、進化させるために 40 年近くも費やしてきました。Auto Trader は 1977 年に出版誌の発行を開始し、2013 年に完全にデジタル化され、それ以来、英国大手のデジタル ブランドになりました。現在、Auto Trader はクロス プラットフォームで月に約 5,000 万のインプレッションを集め、自動車に分類されるプラットフォームの総利用時間の 75% のシェアを占めています。

当社は成長にともない、動きを速める必要があると気付きました。長年にわたりオンプレミス インフラストラクチャに多額の投資を行い、クラウドへの移行を開始するにつれ、当社の財産がクラウドネイティブであることを確実にするうえで大きな進歩がありました。それでも、大幅な見直しなしには実現がますます困難になっている機能が存在しました。2018 年に Google Cloud に移行することを決定し、Google Kubernetes Engine（GKE）を導入しました。こうしたソリューションを活用することで、開発目標の一部をより迅速に実現できると考えたためです。これにより、インフラストラクチャの日常的な構築と管理ではなく、サービスとデータベースに重点を置くことができるようになりました。

プロプライエタリからオープンソースへ

これまでは、大規模なオンプレミスの Oracle データベースがあり、合計でおよそ 200 ものサービスがすべて統合されていました。これはモノリシック アプリケーション開発ではうまく機能しましたが、大規模なデータベースをより小規模なチャンクに分割し、所有するサービスとより緊密に統合する必要があることが明らかになりました。当社の長期的ビジョンは常に、単一ベンダーに縛られることを避けるために、データベースにとらわれないようにすることでした。その結果、PL/SQL のフットプリントは大幅に少なくなりました。Google Cloud SQL は自社環境に無理なく溶け込み、現在はデータストア戦略の中核になっています。

Cloud SQL のフルマネージド サービスにより、通常は多くの労力を要するデータベース メンテナンスの煩わしさが解消されました。アップグレード、バックアップ、パッチ、障害に関するバックグラウンドの管理を Google に任せて、データ エンジニアが学習とパフォーマンス チューニングにより多くの時間を割けるようになりました。

現在に至るまで、Oracle フットプリントの約 65% を Cloud SQL に移行し、約 2 TB（移行前のサイズの 13%）のデータがいくつかのサービスで移行されずに残っています。Oracle フットプリントからの移行と脱却は、2021 年も引き続き戦略的な優先事項です。

移行によりマインドセットを変革

当社の長期目標は、サービスがデータベース エンジンを共有する必要がある統合データベース アーキテクチャから脱却することです。サービスは他のサービスのデータベースではなく、独自のデータストアにのみアクセスできる必要があります。他のすべてのアクセスは、サービスレイヤを介して行わなければなりません。

Auto Trader は移行の基盤が整っており、サービスの 60% 以上がすでに「クラウド ネイティブ」であり、GKE クラスタに移行する前にプライベート クラウドで実行されていました。残りのサービスはクラウド向けに再構築されていたので、ローカルのステートフル ストレージへの依存関係が取り除かれ、水平方向のスケーラビリティが確保されていました。当社はクラウド環境で任意のティアや重要度のサービスをどのように実行する必要があるかについて、明確な一連のルールを設けています。現在のところ、63 のサービスをサポートする 14 の MySQL ベースのインスタンスと、17 のサービスを実行する 11 の PostgreSQL インスタンスがあります。各インスタンスは重要な自動車データサービスをサポートします。あらゆる自動車の詳細が含まれているこのサービスは、インベントリ サービスを強化します。印象的なのは、移行してからパフォーマンスが大幅に向上したことです。また、登録とシングル サインオン サービスも Postgres に最近移行しましたが、大きな障害や混乱はほとんどありませんでした。それ以来、このサービスの Cloud SQL インスタンスのリソースを 5 分以内で簡単にスケールできています。

当社はこの移行の一環として、ユーザーの行動も変えようとしています。所有するサービス以外から Cloud SQL データベースへのプログラムによる直接アクセスを制限して、不明な外部依存関係を回避できるようにしています。こうした依存関係は従来、Oracle の使用時には悩みの種になっていました。

現在では、代わりに Google のデータクラウドを介してデータにアクセスしやすくしました。この方法では、ストリーム処理フレームワークとして Kafka を使用し、通常は Cloud SQL データベース内にある運用データストアからデータを移動して、Google Cloud のエンタープライズ データ ウェアハウスである BigQuery にデータを取り込んでいます。BigQuery に保存されたソースデータは、dbt（データビルド ツール）というツールを使用して処理され、クリーンアップして他の有用なデータセットと結合されてから BigQuery に保存されます。次に、ビジネス インテリジェンス（BI）ツールの Looker を BigQuery に接続して、従業員がビジネス分析情報を探索、分析、共有できるようにします。

Cloud SQL がスピード、自由、イノベーションを実現

Cloud SQL への移行は、チームの働き方に大きな影響を与え、シームレスな開発エクスペリエンスを生み出すことができました。

たとえば、チームからメンテナンスの負担が取り除かれました。以前は、営業時間外にメンテナンスをスケジュール設定していたため、データベース エンジニアは一度に数日間とられてしまいました。メモリと CPU の追加やインスタンスのスケールアップが難しいことではなくなり、意思決定から行動に移すまでのスピードが速くなりました。Cloud SQL は管理が簡単で、チームはメンテナンス パッチに何時間も費やす必要がなくなって、チーム全体の生産性が向上しました。

Cloud SQL により、デベロッパーに新しいインスタンスをプロビジョニングする方法も一変しました。移行する前は、独自のインスタンスを利用するオプションをデベロッパーに提供することさえできず、デベロッパーは、他に何が実行されているかに関係なく統合インスタンスを使用する必要がありました。現在は、Terraform コードを数行書くだけで、1 時間以内に新しい専用インスタンスをプロビジョニングできます。デベロッパーには作業のための独自のスペースと自由が確保されていて、他のサービスに影響を与えるリスクはありません。問題のトラブルシューティングをよりすばやく行えるだけでなく、デベロッパーを Grafana ダッシュボードに直接リンクして、データの可視性を高めることもできます。

Auto Trader が Google Cloud に移行することで可視性、アジリティ、セキュリティがどのように向上したかについて詳しくは、Auto Trader（英国）の導入事例をご覧ください。

-Auto Trader（英国）プリンシパル データベース エンジニア Mohsin Patel