TAXELの単一障害点を解消する

投稿者: | 2020年12月11日

この記事は GMOアドマーケティング Advent Calendar 2020 11日目の記事です。

こんにちは。
GMOアドマーケティングのM.Nです。

弊社ではメディアの回遊性、収益性を高めるため、レコメンドウィジェットの「TAXEL」を提供しています。

TAXELは2018年頃から徐々にオンプレからGCPに移行を行い、2020年9月に全ての機能をGCPに移行しました。
今回は移行時に行った取り組みについて紹介しようと思います。

1.オンプレ時のシステム構成

オンプレ時のシステム構成は下図のようになっていました。
(わかりやすくするために簡略化しています)

全ての機能がHadoopに依存しており、動作に必要なデータをHBaseに集約しているため、Hadoopクラスタに障害があった場合全ての機能に障害が発生してしまいます。
実際によく障害が発生し復旧に手間がかかるという問題を抱えていました。

2.GCP移行後のシステム構成

続いてGCP移行後のシステム構成図です。
(移行前同様、わかりやすくするために簡略化しています)

移行前はレコメンドバッチで作成したレコメンド記事をHiveテーブルに格納し、HBaseでHiveのマッピングテーブルを作成し配信で使用していましたが、移行後では作成したレコメンド記事をGoogle Cloud Storage(以下GCS)に格納し、polling方式でBigtableに転送するように変更しています。
管理画面についても移行前は一部の項目を直接HBaseに保存していましたが、移行後では管理画面はCloud SQLにのみ保存し、同様にpolling方式でBigtableに転送するようにしました。

3.移行してよかったこと

以前に比べ、システムが柔軟になりました。
例えばDataProcやGCSの障害により新たにレコメンド記事が作成できなくなってもBigtableに問題なければ配信を続けることが可能です。

また、Bigtableを他のNoSQL(例えばCloud Memorystoreなど)に変更したとしても、管理画面に影響を及ぼすことはありません。

4.改善したいところ

レコメンド記事などの各種データの格納先としてHiveの代わりにGCSを採用していますが、そのため検索性能が貧弱です。
BigtableではSQLライクな検索方法ができないため、分析や調査に手間取ってしまいます。

実はBigQueryを使用してBigtableに保存されたデータをクエリする機能があるのですが、2020年12月現在、東京リージョンでは利用できないようです。
これに関しては東京リージョンで利用できるようになったら使ってみたいと思っています。

5.さいごに

システム構成を大きく変更するのはなかなか難易度が高いですが、移行というタイミングで思い切ってやることにしました。
特に不具合もなく以前より安定して稼働できているため、やってよかったと思います。

明日は、tfactoryさんによる「GmailとSlackの連携」です。
引き続き、GMOアドマーケティング Advent Calendar 2020 をお楽しみください!

■エンジニア採用ページ ~福利厚生や各種制度のご案内はこちら~
https://www.gmo-ap.jp/engineer/

■noteページ ~ブログや採用、イベント情報を公開中!~
https://note.gmo-ap.jp/

カテゴリー: AM GCP