複數のサービスを比較/検討した結果、2015 年 4 月に Amazon Redshift をはじめとするいくつかの AWS サービスの匯入を決定しました。AWS を選んだ理由は、展開するサービスの多さ、技術的優位性、拡張性の高さなどが他社に比べてすぐれていると判斷したからです。クラウド上のデータウェアハウジングシステムである Amazon Redshift も、小売を含む世界中の多くの企業ですでに十分な匯入実績があることがわかっていましたし、セキュリティについても十分に納得の行く説明を受けることができました。

ただ、移行期間が 4 ヶ月半と非常に短い點が問題でした。小売業界の IT 部門である以上、「店舗への影響は最小限に抑える」は大前提です。システムが止まったり、処理が重くなったりすることで店舗に迷惑をかけることは絶対に避けなければなりません。そのため、ローンチのスケジュールをシルバーウィーク終了後の 9 月の終わりに設定しました。

そこで匯入プロジェクト開始當初の 5 月は「AWS 上で Oracle をどう動かすか」について、要件を洗い出すことからスタートしました。AWS クラウド上に Oracle ライセンスをもっていくという方針で、まずは検証用として、Amazon EC2 上に大きな Oracle DB システムを構築しました。これは店舗の売上データを集約する基幹系の統合データベースで、それまで Exadata のパワーに頼って回していた部分を Oracle Database に合わせてチューニングしていく作業を行っていきました。Exadata 上のデータを Oracle Database 上にエクスポートしながら、負荷はどの程度までかけられるか、アプリケーション側に必要な要件は何か、Amazon EC2 のインスタンスサイズはどのタイプが適切か、といったことを何度も何度も試しながら決めていきました。

このようにテストや検証を簡単に行える、ダメな場合はすぐに変更ができるという點は AWS クラウドならではの大きなメリットだと思います。

Oracle Database で集約した店舗データを Amazon Redshift に渡したあとは、Amazon Redshift 上でバッチ処理や分析を行い、その分析データに対して Amazon EC2 上の Microsoft SQL Server、SAP Predictive Analytics からクエリを投げる構成にしました。最初はデータのインポートに時間がかかっていたのですが、分析アプリケーションを Amazon EC2 上で稼働させることで、參照による負荷を抑えることが可能になりました。それでも重い場合は SQL 側でチューニングしています。

前述したように、最初にサイジングをする必要がなく、何度もテストを繰り返すことができたため、開発期間は予定通り 4 ヶ月半で済みました。今回の移行に合わせて、アプリケーションサーバーのバージョン変更を行う點で若干苦労しましたが、それ以外は移行を段階的に進めることができたため、かなりスムースに運んだプロジェクトでした。クラウドでなければこの期間での移行は実現できなかったと思っています。

プロジェクトが順調だった理由をもうひとつ挙げると、ちょうど 4 月に IT 部門の組織を変更し、インフラ技術者とアプリケーション開発者が一緒のチームで働く DevOps 的な體制を取ったことです。これは本當に偶然だったのですが、AWS はアプリケーションエンジニアがインフラ領域を觸りやすい環境になっているので、「コードを書きながらインフラを構築する」というアプローチを取ることができたのは非常に良いタイミングでした。そしてこの組織変更が良い方向に作用したのは、やはり「必要なものは內製する」という當社の文化があったからだと思っています。DevOps や內製重視といったアプローチの重要性は、今後クラウドが普及するにつれて、より高まるのではないでしょうか。