大規模サービスのAWS移行の進め方

AWS Summit Tokyo 2016 レポート

大規模サービスのAWS移行の進め方 - AWS Summit Tokyo 2016 レポート

こんにちは。ビューティー開発チームの高丸です。
6/1 - 6/3で開催されたAWS Summit Tokyo 2016に参加してきましたので、レポートしたいと思います。(時間の都合でフルでは参加できませんでした……。)

2014年に「クラウドはニューノーマルである」と宣言されてから、大手の企業でも積極的にクラウドファーストのインフラ設計が進められるようになりました。

リクルートライフスタイルでも、クラウド実績はどんどん増えており、私が以前担当していたギャザリーは、社内AWS利用事例の先駆けとなっておりました。

新規にAWSを導入したり、小規模なサービスでの移行は簡単なのですが、大規模なサービスでの移行の難易度は高く、どうやって移行を進めていくかが悩みとなっておりました。
私も、2016年4月からホットペッパービューティーの開発担当になり、SRE (Site Reliability Engineering) の観点から、インフラ面の整備を検討しています。

今回は、大規模な移行をどのようなステップで進めていったかを中心にセッションを聴いてきました。

10 年オンプレで運用した mixi を AWS に移行した 10 の理由

mixi社のセッションで、オンプレからAWSに移行した例がありました。大規模なSNSですが、10年オンプレでやっていると、いろいろ管理が大変になってきたそうです。

memcachedサーバの台数の多さも有名で、AWSとオンプレのハイブリッド構成の時に、どのように工夫したかは気になりました。

大方針

DBはオンプレに残すものの、徐々にAWS側でアプリケーションサーバを移行していき(ハイブリッド化)、アプリエンジニアでも管理できるようなインフラに変えていく方針だったそうです。

Direct Connect

まず始めは、Direct Connectでした。専用線を用意して、データを確実に移行できるようにする第一歩ですね。

Route 53

Route 53の重み付けラウンドロビンを利用して、AWS⇔オンプレの振り分け割合を、徐々にAWS側に寄せていく方法でした。いきなりAWSに100%に振るのはリスクがありすぎるのですが、ここでRoute 53が役に立ちます。

AWS側にもmemcached (ElastiCache)

memcachedサーバをAWS側にも用意し、DCをまたいだ通信をなるべく少なくする工夫などがされていました。

ストレージデータ移行

S3にインターネット経由でアップロードし直していたので、6ヶ月ほど掛かったそうです……。今なら、Snowballでどーんと移行するのもありだそうです。

AWS APPサーバ→専用線→オンプレDB

ここはしっかりと検証が必要だなと思った部分で、DCをまたいだDBへの通信になりますので、レイテンシを気にする必要があります。
オンプレにDBを残す例は多いと思います。アクセスとしてはReadが多いらしく、memcachedでキャッシュが効かせられるので、この構成ができたのかもしれません。

レコチョク全システム AWS 移行完了

レコチョク社は、2014年のAWS Summit Tokyoでも発表されていたそうで、今回は全面移行のお話でした。

コスト面をどう見積もるかだったり、乗り気じゃないメンバーをどう説得するか、AWSの教育をどう進めていくかなど、参考になる部分はたくさんありました。
中でも、「メンバーをre:Inventに連れて行って、移行のモチベーションにする」というのは、荒業で面白かったです(笑)

技術的なトレンド

正直、LambdaとAuroraはもう堅いなと思いました。

「Lambdaファースト」の設計思想も出てきています。システムの間を埋めたり、データ連携したりが得意のLambdaは、サービスの規模に関わらず、今回事例共有がとても多かったです。
バッチなんぞ作らずに、Lambdaでスマートな構成にしたいですよね。

あとは、Aurora。シーケンシャルリードが遅いといった事象共有もありましたが、最近ではクロスリージョンリードレプリカも対応し、万全を期しています。
オンプレのDBが置き換わる事例は、ますます増えそうです。

セッションは見られなかったのですが、DevOpsのセッション中に「CodePipeline 最高!」みたいなTwitterのタイムラインになっていました。が、まだ東京リージョンにやってきておりません。

おわりに

金融システムでも導入が進むクラウド。ハイブリッドな構成はもちろんのことですが、どのように移行ステップを登っていくかがとても重要に感じました。
AWSも CAF (Cloud Adoption Framework) を提唱しており、大規模な移行も、より安全な実施が可能になると思います。
とは言うものの、ハイブリッド化までに2年を掛けている例もあり、長い道のりであることも改めて感じました。

アーキテクトとしての知識を蓄えられた3日間でした!

高丸 翔英

(ビューティー開発チーム テックリード)

エンジニアドリブンで大規模サービス開発をしています。

NEXT