セールスフォース・ドットコムが東京データセンターに国内顧客約5000社の移行完了。その裏側を聞いた

2012年1月23日

セールスフォース・ドットコムは、米国西海岸とシンガポールのデータセンターにあった国内顧客のクラウド環境を、昨年12月に開設した東京データセンターへ移行する作業が1月15日に完了したことを明らかにしました。

同社によると国内の顧客は約5000社。移行作業は昨年2011年10月からはじまり、2012年1月15日日曜日に完了したとのこと。

同社代表取締役社長宇陀栄次氏は「弊社のクラウドサービスは、お客様の既存の情報システムとさまざまな種類の連係が緊密に行われている。しかし今回の移行に際して、お客様側でのシングルサインオンの移行設定し忘れなどによる軽微な問題はあったものの、ほとんど何の問題なく移行が完了した。私のIBM時代の経験も含めて言えばデータセンターの移行にトラブルはつきものだが、今回は非常にすんなりといって正直びっくりした」と、今回の移行を振り返っています。

左から、CTO 及川喜之氏、代表取締役社長宇陀栄次氏、専務執行役員アライアンス＆サービス統括本部長保科実氏、サポートサービス本部長佐藤太亮氏。無事に移行が終わった安心感か、表情が晴れ晴れしている感じを受けた

クラウドでSaaS/PaaSを提供するベンダとして、大規模移行を短期間で無事に実現した同社に、移行の内容と背景を聞きました。

昨年10月から順次移行、1月15日に完了

東京データセンターへの移行対象となったのは、主に日本の顧客が収容されている米国西海岸データセンターの「AP0」インスタンスと、日本以外のアジア太平洋地域の顧客が収容されているシンガポールデータセンターの「AP1」インスタンス。さらに、それぞれのサンドボックス（試験環境）である「CS5」「CS6」インスタンスの合計4つ。

同社のクラウドは複数のデータセンターからなり、1つのデータセンターでは複数のインスタンスが稼働しています。インスタンスは複数の顧客を収容するマルチテナント構造となっています（同社のクラウドアーキテクチャについては、記事「セールスフォースのアーキテクチャ（物理アーキテクチャ編）～ Podによるスケールアウト」を参照）。

移行は、まずサンドボックスであるCS5が2011年10月23日に完了、続いて本番環境であるAP1が12月3日に完了、CS6が12月6日に完了し、2012年1月15日にAP0が完了して、東京データセンターへのすべての移行作業が完了しました。

移行後もインスタンス名、URLなどは変わらず、基本的に同社のサービスを通常利用しているだけならば移行前と後を区別することはできません。「変わったことは物理的な位置と、それに伴ってIPアドレスが変わっただけ。お客様の側でアクセス制限のホワイトリストなどにIPアドレスを直接書き込んでいる場合に変更が必要な程度」（アライアンス＆サービス統括本部長保科実氏）。「Tracerouteを実行して確認しなければ、違いには気がつかないでしょう」（CTO 及川喜之氏）。

先にサンドボックスを移行することで、顧客はサンドボックスを用いて移行後に問題が発生しないかどうかを試すことが可能だったことも、移行トラブルを未然に防ぐことに貢献したようです。

一方で大きく変わった点も。「東京データセンターに移ったことでレイテンシが非常に改善されており、大量のレポートを発行するようなI/Oが大きいお客様ではレスポンスが半分くらいになったと聞いている」（保科氏）。Webブラウザからの利用でも体感速度があがったとのことです。

「国内データセンターへの安全な移行や性能向上も、機能追加を含めた定期的なアップグレードも、私たちは追加料金なしで毎月の料金だけで行っている。これこそクラウドが提供できる価値だと思っている」（宇陀社長）

基本的にディザスタリカバリと同様の手順で移行

セールスフォース・ドットコムによる移行作業はどのように行われたのでしょうか。同社CTO 及川氏に聞きました。

「基本的にはディザスタリカバリと同じ方法だ。弊社のディザスタリカバリは縮退せず、100％まったく同じ能力の機材を別のデータセンターに用意して切り替えるものなので、今回の移行も同じ方法で行われた。基本的には遠隔地へレプリケーションを行い、スイッチを切り替えるという手順になる。

ディザスタリカバリのテストは北米で何度もやっていて手順もできており、間違える要因がないよう、ハードウェアに多少に新旧はあっても世界中どこのデータセンターも同じ構成になっている。もちろん移行手順の細かい変更はあって、今回も作業をするごとに反省会を開いて手順をブラッシュアップしていった。」（及川氏）

「システム移行でトラブルがおきやすいのはネットワークのほうだが、その辺はNTTコミュニケーションズさんが綿密な移行計画を作ってくれた。その手順はたいへん参考になった」（宇陀社長）

マルチテナントアーキテクチャがシンプルさの要因

東京データセンターへの移行を容易にした最大の要因は、同社のクラウドが採用するマルチテナントアーキテクチャ。

同社のインスタンスは、1つのデータベーススキーマ、1つのプログラムコードで実現されたアプリケーションを利用者全員が共有しているものです。そのうえで利用者ごとにメタデータを用いることで、論理的なデータベーススキーマとアプリケーションのカスタマイズを可能にしています。

つまり、利用者が何社で何人であろうとも、インスタンスにはデータベースが1つ、アプリケーションが1つしかないのです（カスタマイズ用メタデータもデータベースに格納されます）。これが同社のマルチテナントアーキテクチャの大きな特徴の1つです。

コードをコピーしてデータベースをレプリケーションする、これだけでインスタンス内の全顧客の移行が終わる、ということになります。

サポートサービス本部長佐藤太亮氏は「普通、データセンターの移行はお客様ごとに環境も手順も違うため、どこかでミスも起きる。私どもも今回は二重三重のサポート体制を組んでいたが、何もなくて拍子抜けしたほど。マルチテナントアーキテクチャのおかげで、すっとできたというのが印象」と、マルチテナントアーキテクチャによる移行のシンプルさを語っていました。

同社のマルチテナントアーキテクチャについては、以下の記事を参照してください。