【事例レポート】DX成功はAmazon RDSからAlloyDBへの完全移行にあった #GoogleCloudNext

【事例レポート】DX成功はAmazon RDSからAlloyDBへの完全移行にあった #GoogleCloudNext

type就活のAWSからGoogle Cloud(特にAlloyDB)への移行事例について、課題、プロセス、そして得られた成果をレポートにまとめます。
Clock Icon2024.08.02

概要

今回はtype就活さんのGoogle Cloudデータベースの活用事例セッションについてのレポートを書きます。
内容は、表題の通りAWS RDSからGoogle Cloud AlloyDBに移行した時の事例をもとに、その時の苦労やメリットを話していただけました。

※ 本ブログでは、登壇者や関係会社の個別紹介は控えさせていただきます。また、会社名およびサービス名の敬称は省略いたします。

前提

課題

type就活は学生の就職支援サービスを運営する会社様です。

コロナをきっかけにtype就活の学生へのアプローチ方法が大きく変わったことで、システムの基盤を移すきっかけになったそうです。

スクリーンショット 2024-08-02 9.00.46

リアルイベントからオンラインイベントになり、集団から個人へ変化したことで、ビジネス上のアプローチ方法を変える必要があったとか。

やらなければならないこと

企業としては以下の目標を掲げていました。

  • お客様採用へのコミット
  • ターゲット層との接点数、質の最大化
  • 質の高い本質質的なコンテンツの提供

上記の目標にアプローチできるITコンテンツを達成することも視野にいれて、Google Cloudへの環境移行を検討した模様です。

さらに、学生一人ひとりに焦点を当てたアプローチが必要となった際、より強く認識したのは、データ活用の重要性でした。

また、元々は、ブースでの対応というオフラインのアプローチがメインであったため、オンライン化した時の事例が無く、知見0からのスタートであったためかなり苦戦したようです。

システムサポートさんのアプローチ

ADDPLATを導入

tyep就活を支援したのがシステムサポート株式会社です。
ADDPLATとは、システムサポートの自社サービスのようで主にBQ+Lookerを活用したデータを活用するアプリです。

スクリーンショット 2024-08-02 8.28.52

そして、今あるデータをまず分析し、そしてどのようなデータがあるかを把握することから始めたことが最初のアプローチのようでした。

さらに、もともとエクセルにあったデータを、Lookerを使用して可視化することで、ビジネスユーザーでもデータにアクセスでき業務効率化に貢献しました。

AWSからGoogle Cloudへの移行

インフラ環境の移行の際には、もともとのAWS環境と親和性の高い構成にするように意識したらしく、その理由として、なるべくインフラ面のみの変更に抑えたかったから(さまざまなコスト面を考慮して)。

(画像が荒いのでコンポーネントが見えないですが)
スクリーンショット 2024-08-02 8.31.28

また、AWS環境時には自動スケールを採用せず、都度サーバーやDBのスペックを上げていたことで高負荷のアクセスに対処していたが、環境移行に伴い、オートスケールの仕組みを組み込んだことも功を奏しました。

先程お伝えした、ADDPLATはGogole Cloud環境で作成されているため、ADDPLAT内のデータともシームレスな連携が実現できたようです。

RDSからAlloyDBへの移行

そして、RDSではMySQLを使用していましたが、Google CloudではAlloyDBを採用し、PostgreSQLに移し替えたとのこと。(ちなみにMySQLとPostgreSQLに互換性はありません)

この時にPGLoaderを採用したことにより、移行をスムーズに達成できたとのこと。
要件として、type就活サービスの停止時間をできるだけ少なくしたく、それにマッチしたのがPGLoader機能でした。

ちなみにPGLoaderとは、今回のようなデータベース間でデータを移行するために使用するオープンソースツールです。
主にPostgreSQLデータベースへのデータ移行に使用されますが、他のデータベースシステムからのデータ移行にも対応しています。
https://pgloader.io/

なぜAlloyDBを採用したのか

1722497331602

特にカラムナエンジンの採用が決めてでした。通常のデータベースはレコードごとにデータを扱うため、分析クエリを流そうとするとテーブル全体をスキャンしてしまい、処理に時間がかかってしまいます。

しかし、カラムナエンジンを搭載したAlloyDBであれば、列ごとにスキャンが可能なので、処理に時間が早くなります。

また、AlloyDBにはクエリインサイトというクエリのパフォーマンスを可視化できる機能も含まれており、AWS環境で実行していた時よりもクエリの処理時間が短縮したことも確認できたそうで、90%以上短縮したクエリもありました。

まとめ

1722497331598
今回のAWSからGoogle Cloudへの移行に際しては、オフラインからオンラインという未知の土俵で挑戦することになったにもかかわらず、年間の大規模イベントの参加者数が増え、さらにサーバーとデータベースのCPUともに負荷が削減され、サービス/システムともに成功でした。

_storage_emulated_0_Android_data_com.miui.gallery_cache_SecurityShare_1722497331594

また、今後の展望としては、生成AIの導入による機能の追加などを視野に入れており、サービス自体の価値向上を目標にしたい(業務効率化など)という理由があるそうです。

この記事をシェアする

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.