講演資料
試行錯誤の新アーキテクチャ移行
楽天では11年前から、同社サービスの画像を格納、API連携で提供するストレージサービスを運用してきた。フロントの楽天サービスが画像をリクエストすると、楽天データセンター内にあるプロキシサーバーのSquid（*1）からVarnish（*2）内のキャッシュに問い合わせが実行され、キャッシュがなければリバースプロキシのPerlbal（*3）経由でMySQLやMogileFS（*4）へのAPIを叩き、結果を返すといった構成だ。
*1 Squid
*2 Varnish Cache
*3 Perbal proxy
*4 MofileFS
「課題はさまざまあった。メンテナンスやバージョンアップの計画が難しく、アクセス負荷が増えたときの増強も大変。また、MogileFSには大量のデータが格納されており、容量の問題から仮想ディスクではなく物理ディスクを使っていたが、足りなくなったり、故障すると交換するしかない昔ながらのスタイルだった」（柳本氏）
この旧アーキテクチャを、Microsoft Azureを使って刷新した。まず、CDN（Contents Delivery Network）にキャッシュを置き、Microsoft Azure上のTraffic Manager（*5）でロードバランシングしながら、KubernetesのAPIポッド経由でMogileFSから代替したAzure Blob Storage（*6）へデータを格納または取得を実施。メタデータについては、Azure ExpressRoute（*7）経由で楽天データセンター内のMySQLに問い合わせる構成にした。
*5 Traffic Manager：DNSベースのロードバランサー
*6 Azure Blob Storage：オブジェクトストレージサービス
*7 Azure ExpressRoute：オンプレミスとクラウドを閉域網で接続
「実は最初、SquidとVarnishをKubernetes内にポッドで残して、分散KVストレージやセグメンテーションなどを提供するHashiCorp Consulでサービスをディスカバリし、Varnishが死んでもコンフィグの書き換えや自動復旧をやるような構成を考えていた。でも、構成を組んだあとで、Azureはアウトプット時に課金されるので、この構成だと課金がかさんでいくシステムなんじゃないかと気付いた」（柳本氏）
Varnishでキャッシュする意味がなかったと苦笑いしながら、CDNのキャッシュで90％はリクエストに返せるように設計し直したと柳本氏は明かす。
「クラウドを活用するときは、課金の仕組みをしっかり確認し、構成にもよるがキャッシュは効率的な形で配置。また、アーキテクチャはシンプルに保つようにするのが最適と学んだ」（柳本氏）
ちなみに、楽天データセンター側にMySQLを置いた理由について、柳本氏は「Azure Database for MySQLはハードウェア障害時に予告なしで中断するほか、メンテナンスは不定回数、10数秒の停止を事前予告なしで実施するから」とし、計画停止など調整が可能な自社データセンターで落ち着いたと述べた。
これに対して日本マイクロソフトの新井庸介氏は、「Azure Database for MySQLの計画メンテナンスにおいて、事前通知やタイミングの指定が現状行えないのはそのとおり」と説明。だが改善は進んでおり、最大72時間前に通知するプレビューがまずUKとUSで始まっている（*8）。またメンテナンスタイミングについては、Azure Synapse Analytics（旧称 SQL DW）、Azure Cache for Redis、Azure VM（on Azure Dedicated Host（*9））等、既に指定可能なサービスはあり、順次他サービスでも実現していきたいとした。
*8 Azure Database for MySQL：計画メンテナンスの通知（Preview）について
*9 Azure Dedicated Host：専用サーバーをサービスとして提供するクラウドサービス
これを受けて柳本氏は、「計画停止にせよ障害にせよ。そもそも論としてデータベースも落ちるものだという前提で、例えば前段にメッセージングやキューイングの仕組みを導入することも考えたい」と考えを述べた。
データ移行についても大変だったと柳本氏は言う。旧MogileFSには約15億レコード、約260TBのデータが格納されていた。これをどう移行させるかで悩んでいたところ、マイクロソフトからAzure Data Boxを紹介されたと柳本氏は述べた。Azure Data Boxはオフラインでデータ転送するためのハードウェアで、7TB・80TB・770TBの3種類から選べる。
「日本では7TBと80TBが利用できる。260TBであれば80TBモデルを複数台使えばいけるかなと思ったが、残念ながら今回の要件にはあわなかった」（新井氏）
採用を見送った理由は、Rails ６系のActive Storage（*10）機能を使っている関係上、データ移動とメタデータの更新をセットで行う必要があったからである。単純にコピーして移すことができず、結局はネットワーク越しで順次移行していると柳本氏は説明する。
*10 Active Storage概要
だが、これもなかなか手ごわく、ネットワーク帯域の圧迫を最小限に抑える、Active Storageのメタデータ更新中にイメージをつかんでいるせいでメモリリークを起こさないように気を付ける、スキーマの変更の有無で苦労レベルは変わるので注意するなど、「気を遣いながら原始的にゴリゴリやっている」と明かす。
「特にデータが大量であれば、新しいアプリケーションを完全に違うバージョンで提供することにして、アプリケーションごとに切り替える方がうまくいくように感じる」（柳本氏）
なお、最近東日本でGAになったAzure Stack Edge（*11）であれば、エッジ側でデータを処理しメタデータを生成する等が可能と新井氏は言う。AI/ML、Stream Analytics、FunctionsなどのクラウドサービスをAzure Stack Edge上で利用し、単なるデータコピー以上の柔軟な処理が可能という。紹介を聞いて柳本氏も興味を示し、タイミングが合えば試してみたいと述べた。
*11 Azure Stack Edge
