【TECH BLOG】オンプレのreadonlyデータベースをクラウド化した話

はじめに

こんにちは、技術本部SRE部ZOZOSREチームの堀口／柳田です。普段はZOZOTOWNのオンプレミスとクラウドの構築・運用に携わっています。

ZOZOTOWNではSQL Serverを中心とした各種DBMSが稼働しています。

その中で検索処理における参照に特化された役割を持つデータベース群をReadOnlyデータベース（以下、RODB）と呼んでいます。これらは日々増加するZOZOTOWNのトラフィックに耐えられるよう定期的にオンプレミスサーバを増台することでスケールしています。

これらのRODBは日々トラフィックの増減が激しいZOZOTOWNのサービスにおいて、オンデマンドでスケール可能なクラウド基盤上に構築した方が望ましいと判断し、クラウド化を実現しました。

本記事では、オンプレRODBをAWS RDS for SQL Server（以下、RDS）へクラウドリフトする中で解決すべき課題とそれをどのように解決したのかを紹介させて頂きます。

クラウド化する上での課題

RODBをクラウド化するにあたって以下の課題がありました。

1. アクセス元のアプリケーションロジックを変更せずに実現する必要がある
2. オンプレ⇔クラウド間の通信量を削減する必要がある
3. クラウド側の障害でもサービス影響を最小限に抑える必要がある
4. コストを最小化する必要がある

これらの課題を1つずつ説明していきます。

アクセス元のアプリケーションロジックを変更せずに実現する必要がある

RODBのアクセス種類は2種類あります。

• Webサーバ上で動作するアプリケーションからの参照処理（select）
• データ更新のためのデータレプリケーション（update/insert/delete）

アプリケーションからの参照処理におけるRODBへ接続する際のDBログイン方式は、ユーザ名＋パスワード指定による一般的なSQL Server認証方式ではなく、Windows認証方式となっています。

今回のクラウド化で置き換えるサービスはAWSのマネージド型データベースであるRDS for SQL Serverと決定していました。しかし、RDSはPaaSであるゆえに既存のRODBが所属するWindowsドメインに所属させることができません。

これではWindowsログオンユーザでDB接続するWindows認証方式が使用できないことになります。

RODBへのログイン方式を変更することは、Webサーバ上で動作するアプリケーションソースを書き換えることになります。これではオンプレRODB向けなのかクラウドRODB向けなのかをアプリケーション側に意識させる必要性が生まれてしまいます。

これはインフラとアプリケーションが密結合してしまい、本来目指すべき方向から外れてしまいます。ましてやアプリケーションソースをオンプレRODB向け／クラウドRODB向けと二重管理することは絶対に避けたいものです。

RDSへのログイン方法をWindows認証でログインさせる方法がないか模索したところ、AWS側に用意されていました。

「AWS Managed Microsoft AD」というマネージド型のディレクトリサービスにRDSを所属させ、それと既存のドメイン間で信頼関係を作成するというものです。

これによりRDSへのログイン時に既存ドメイン上のユーザがWindows認証によりSQL Serverにログインが可能となりました。

より詳細な情報は下記に記載されていますので興味のある方はこちらを参照してください。

この仕組みによりアプリケーション側のログインロジックを変更することなく、オンプレDBとRDSへのログインを実現できました。

AWS Managed Microsoft ADの落とし穴

AWS Managed Microsoft ADについては当初知見がなく、構築時にハマった箇所を少し紹介します。

AD自身のアクセス制御を行うSecurityGroupについてです。AWS Managed Microsoft AD上にディレクトリを作成すると、AWSの命名規約に則ってSecurityGroupが自動的に生成されます。このSecurityGroupはAWSマネジメントコンソールから該当ディレクトリを参照しても変更できません。その存在すら見当たりません。SecurityGroupを変更したい場合は、自分で該当SecurityGroupをEC2サービス側から探し出し、変更する必要があります。

また、上記SecurityGroupを発見できたとしても、信頼関係を結ぶ他のドメインコントローラーとの通信で必要なポートが不明瞭です。AWSのマニュアルで指定されたポートだけでは不十分で、実際には他のポートも開ける必要があります。不足分はトライ＆エラーで調査しました。

オンプレ⇔クラウド間の通信量を削減する必要がある

ZOZOTOWNではオンプレミスサーバ群が配置されているデータセンターからAWSサービスまでの通信はAWS Direct Connect（以下、DX）を利用しております。

今回も既設のDX回線を利用するのですが、RODBへのアクセスによりネットワーク帯域を枯渇させることがないように、また枯渇させないまでも通信量の増加を最小限にするよう配慮する必要がありました。

繰り返しになりますが、RODBのアクセス種類は2種類あります。

• Webサーバ上で動作するアプリケーションからの参照処理（select）
• データ更新のためのデータレプリケーション（update/insert/delete）

Webサーバ上で動作するアプリケーションからの参照処理（select）における通信量削減

ZOZOTOWNのWebサーバ群はオンプレミス、AWSの両方で稼働しています。

Webサーバ群はオンプレミス上で稼働しておりそこからRDSへアクセスすると、発行されたクエリ自身とその結果セットの通り道はDXとなります。

これを削減するためRDSへアクセスするWebサーバ群はEC2で稼働するWebサーバのみに限定しました。

オンプレミスのWebサーバからのアクセスはオンプレRODBにするといった棲み分けを行うことでオンプレ⇔RDS間の通信をゼロにしました。

続きはこちら