Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オンプレからAWSへの移設とそのヒント
Search
CyberAgent
PRO
February 22, 2019
Technology
2
990
オンプレからAWSへの移設とそのヒント
サイバーエージェントの技術者(エンジニア・クリエイター)向けカンファレンス『CA BASE CAMP 2019』
オンプレからAWSへの移設とそのヒント
CyberAgent
PRO
February 22, 2019
Tweet
Share
More Decks by CyberAgent
See All by CyberAgent
2025年度 生成AI 実践編
cyberagentdevelopers
PRO
3
200
LLMを用いたメタデータベースレコメンド検証
cyberagentdevelopers
PRO
6
1.5k
CodeAgentとMCPで実現するデータ分析エージェント
cyberagentdevelopers
PRO
1
240
SQL Agentによるタップルのデータ利活用促進
cyberagentdevelopers
PRO
1
420
NAB Show 2025 動画技術関連レポート / NAB Show 2025 Report
cyberagentdevelopers
PRO
1
390
【2025年度新卒技術研修】100分で学ぶ サイバーエージェントのデータベース 活用事例とMySQLパフォーマンス調査
cyberagentdevelopers
PRO
7
10k
【CA.ai #1】未来を切り拓くAIエージェントの可能性
cyberagentdevelopers
PRO
3
160
【CA.ai #1】MCP世界への招待:AIエンジニアが創る次世代エージェント連携の世界
cyberagentdevelopers
PRO
2
160
【CA.ai #1】ABEMA のコンテンツ制作を最適化! 生成 AI × クラウド映像編集システム
cyberagentdevelopers
PRO
0
140
Other Decks in Technology
See All in Technology
使いたいMCPサーバーはWeb APIをラップして自分で作る #QiitaBash
bengo4com
0
1.9k
Lufthansa ®️ USA Contact Numbers: Complete 2025 Support Guide
lufthanahelpsupport
0
190
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
200
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
2
21k
SaaS型なのに自由度の高い本格CMSでサイト構築と運用のコスパ&タイパUP! MovableType.net の便利機能とユーザー事例のご紹介
masakah
0
110
How Do I Contact HP Printer Support? [Full 2025 Guide for U.S. Businesses]
harrry1211
0
120
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
2
7.7k
無意味な開発生産性の議論から抜け出すための予兆検知とお金とAI
i35_267
4
13k
NewSQLや分散データベースを支えるRaftの仕組み - 仕組みを理解して知る得意不得意
hacomono
PRO
2
130
Should Our Project Join the CNCF? (Japanese Recap)
whywaita
PRO
0
340
FOSS4G 2025 KANSAI QGISで点群データをいろいろしてみた
kou_kita
0
400
高速なプロダクト開発を実現、創業期から掲げるエンタープライズアーキテクチャ
kawauso
2
9.2k
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
36
2.8k
Code Reviewing Like a Champion
maltzj
524
40k
A Tale of Four Properties
chriscoyier
160
23k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Designing for Performance
lara
610
69k
A better future with KSS
kneath
238
17k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
181
54k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Transcript
I-01オンプレからAWSへの移行と そのヒント ホールE-16:00-16:30 須藤・Torgayev・庭木・長谷部・小林
登壇者の紹介 に移設した理由 移設計画 データの移行について まとめ
登壇者の紹介
ティーマ 2017年2月 内定者アルバイト入社 サイバーエージェント 技術本部 サービスリライアビリティグループ (SRG) 2018年4月 サイバーエージェント新卒入社 SRG配属
AWS (特にECS、Lambda)、Elasticsearch、Terraform、 Datadogを専門とし、メディアの新規 立ち上げサポート、既存サービスの改善に携わる メディアのTerraform共通化プロジェクト立ち上げ AWA、REQU、タップル誕生、CROSS MEを担当
庭木 勝也 2012年 C.A.MOBILE 新卒入社 FanaTech 開発局 DC運用、OpenStack導入や、DC間のサービスの移 管、買収サービスのAWS移管にも従事。 2017/7月からは、社内システムも追加で担当。
現在は、新規サービスの開発でGKEとIstioに注力
長谷部 充洋 2018年7月 中途入社 サイバーエージェント SGE統括本部 技術統括室 2012年7月にサイバーエージェントに入社 NBU、アメーバ、アドテクにてインフラエンジニアを担当 一度退職し、某クラウド事業者にてサポートエンジニアに従事 2018年に再度入社し、現在は
SGE管轄内で主にインフラに 関連する部分の技術支援を担当 好きな AWS のサービスは Auto Scaling
小林 邦明 2012年 CA Advance 中途入社 2013年 サイバーエージェント アドテク本部 移動 Strategic
Infrastructure Agency Group Solution Architect Team 所属 アドテク本部内で開発される各サービスのインフラ技術 支援を担当 オンプレ、社内クラウド、AWS、GCPと多様な 環境だが、一番好きなのはAWS
須藤 涼介 2006年 サイバーエージェント アルバイト入社 技術本部 サービスリライアビリティグループ(SRG) マネージャー カスタマーサポートから1年弱でインフラエンジニアに転 向、アメーバピグや各種ソシャゲ、AbemaTVなどメディ ア事業のサービス立ち上げや運用を経て、現在はメディ
ア事業のインフラ領域を横断的にサポートするSRGの マネージメントを行う
に移設した理由 移設のきっかけ なぜ を選んだのか
に移設した理由 • に移設した実績があった ◦ • データセンターの基幹スイッチなどハードウェアの保守切れ ◦ 、セルフィ、アドテク本部 • オンプレを保守運用する人員の確保問題
◦ 、セルフィ • サイバーエージェントグループ内の豊富な利用事例 ◦ セルフィ、アドテク本部、タップル • マネージドサービスを導入していきたい、オートスケーリングを利用したい ◦ タップル
移行計画 タップル誕生
タップル誕生
タップル誕生 • 趣味で繋がる恋活サービス • 会員数 万人以上、マッチング数は延べ 億 万組 • 国内最大規模
https://tapple.me
1. データ層以外のものはオンラインで移設できるから、 メンテ入れてデータ層だけを先に移設させる 2. アプリ層をアーキテクチャ変えず持っていく メンテ入れず、徐々に切り替え 3. マイクロサービス化などの改善 ポイント:小さく進めて「チェックポイント」を作っていく データを先に持っていく理由:パフォーマンスの問題
タップル誕生: 移設計画
1 6 Before
• マネージドにできるものはマネージドにする ◦ Redis → ElastiCache (Redis) ◦ MySQL →
RDS (Aurora) • マネージドにできないものはそのまま持っていく ◦ MongoDBそのまま持っていく (各アプリサーバに乗っているmongosをプロキシに使う) ◦ Elasticsearchもそのまま、ALBでアクセスを分散 • Private CloudからAWSデータ層へのアクセスはDirect Connect経由 (途中でmuninとsensuがDatadogにリプレイスされて、 Jenkinsとpostfixが消える) タップル誕生: 移設
1 8 After step 1 ほぼそのままAWSに
タップル誕生: 移設 • 構成を大きく変えず、アプリ層をそのまま持っていく ◦ 仮想サーバ → EC2 Instanceとして持っていくだけ ◦
EC2 Auto Scaling Groupを利用 ◦ haproxy、nginxをALBにリプレイス ◦ 静的コンテンツの配信は、S3+CloudFront • APIアクセスはRoute 53 Traffic Flowで徐々に段階的に流す ◦ xx% でオートスケールでピーク捌けるか? ◦ 問題が起きたらすぐ切り戻せる
After step 2
Traffic Flow
タップル誕生: 移設 コンテナ化構成、を一旦大まかに • API: ECS EC2 Type • Batch:
ECS Fargate Type (スケーリング設計簡略化) • MongoDBへのアクセス: mongos専用EC2 Instance x3経由 • ログ周り: Kinesis+Lambda 今後のマイクロサービス化へ…
After step 3
タップル誕生:まとめ • データ層の移行はメンテ入れる • アプリ層はRoute 53 Traffic Flowでオンライン切り替え • スモールスタート
• 切り戻しが難しいものを最後に持っていく ◦ ただし、パフォーマンスなど、先に解決したい課題があれば、 そこからスタートしても良し • 一気にアーキテクチャを変えない • 小さく進めて「チェックポイント」を作っていく
None
が展開する事業 音楽 芸能 ヘルス ケア 占い スポーツ ローカ ライズ 占い・芸能・音楽・ヘルスケア・スポーツ・ユーティリティ
… 様々なジャンルのWebサイト、アプリを提供。 海外アプリのローカライズも実施。
移設概要 • 主な移設実施期間 月 月 • 、 で提供している約 サービス ◦
関連部署は つ ◦ 占い・アーティスト・コンテンツ・課金、整合システム • キャリア課金・クレカ課金あり • の課金システムを統合 • エンジニア主導
移設計画と 移設計画 • 決済基盤を構築する 複数環境をマージ • アプリケーションの変更はしない • システム構成の共通化 •
メンテナンスは、分けて実施 ◦ キャリア決済で最低 回実施 • のサービスの精査、クローズを実施 • エンジニア主導で移設を推進 • 全社朝会やポスターを利用し社内の認知度向上 • 行けるものからどんどん移設 その他Tips • 決済システムに想定外のサービスのログがないか調査 • キャリアは ヶ月前には、サービスクローズ申請手続き • テスト端末は早めに確保して、課金可能額も確 認 • テスト利用時の を コードを印刷して準備 • 打ち合わせ、移設時にホワイトボードを利用 ◦ 進捗と認識を合わせ写真に記録し共有共有 • メンテ時に発生した事象をポスト・イットに書き、対処できる 人にアサイン たくさんあるが、 つだけ紹介
メンテナンスは分けて実施 データベース 決済 ウェブアプリケーションに分けて実施 1. AWS Direct Connectを利用し、データベースを先行して移設 2. 決済を移設
3. ウェブアプリケーションやバッチなどを移設 よかったこと ・複数回実施することで、問題発生時の切り分けがスムーズに!!! ・準備までの作業者のタスクやメンテナンス時の作業がより明確に!!! ・決済切り替えが、 サービス合わせて、 時間で終わることも!!
テスト端末 (フューチャーフォン)は早めに準備を! • キャリア契約年数によって、 ヶ月の課金上限金額が異なる • 移設サービスが多いため、課金上限に達する 移設開始時に端末が足りなかった → のみ新規契約で
を 枚ほど追加購入 → 部署間で運用利用端末を貸し借り → テスト端末の手配は移設推進グループで実施
移設に利用した技術 CI・バッチ 監視・外形監視 bot ・通知・コミュニケーション 開発環境・コード管理 ログの管理 アプリケーション Amazon S3
Memcached Redis Amazon ECS Amazon RDS メール送受信・配信 Cloudformation Amazon EFS AWS Batch
Google Big Query Amazon S3 Fluentd aggregator Fluentd collector container
Network LoadBalancer ECS Instance Application LoadBalancer DatadogAgent container Dashboard Service container ローカル環境 ECR ECS Instance 共通化した構成
前編、後編の二部構成で本日公開 エンジニアブログ
データの移行について セルフィ アドテク本部
セルフィ
セルフィ • 株式会社ジークレストによる開発・運営 • 「セルフィ」と呼ばれるオリジナルアバターを着せかえて遊ぶア バターゲーム • スマホ/PC向け • 超長期運用(12年超)
セルフィ:システム紹介 • 構成 一般的なウェブアプリケーション アプリケーションサーバ / DB / キャッシュ /
NAS (共有ストレージ) • データ層 RDB(PostgreSQL / MySQL) 複数系統で合計 4TB くらい NAS NFSでマウント、主にアバター画像など 合計 3TB くらい
セルフィ:移設の概要 • 期間 技術選定や調査などを含めて10ヶ月程度 • 使用している主なサービス Route53 / ELB /
EC2 / ElastiCache / S3 • 今回のスコープで使用を見送ったサービス Amazon Aurora / DMS / EFS (直前で東京リージョンでリリース )
セルフィ:データ層の移設の方法 • PostgreSQL / MySQL DMS を検証するもうまくいかず → 結局、通常のレプリケーション機能で同期 •
NAS rsync でざっくりと同期 更新差分についてはログに残して一定間隔で同期
セルフィ:移設を振り返って • DMS は素晴らしいけど要検証 一部の DB のテーブル構成に起因して、特定のデータが正常にコピー されず、DB の集約および Aurora
への移行を断念しました。 大半のケースでは DMS は力を発揮するツールですが、 きちんと事前に検証しましょう。 ※ソース DB 側(移行前の既存環境)のスキーマを変更すればよかったのですが諸々の事情で変更できず。 • 東京リージョンではまだ使えなかったサービス EFS は移設予定日の直前にローンチされるも検証時間不足で断念。
アドテク本部
アドテク本部 • ~ サイバーエージェント グループ各社でアドテクノロジー関連の 開発をしていた各社が集合して立ち上がった組織 • 常時 程度のサービスを運営 開発中
• アドテク以外にも 、ロボット インターネット広告本部用システム 、
• 対象はインターネット広告本部のMysqlDB • IO Drive搭載のオンプレ環境からAuroraへ • 5セット(10台)を1(2台)セットに • 無停止移行を希望(切替時の寸断は可) アドテク本部:
移設計画とポイント
• DB1台あたり1TB~10TB • レコード数は1Table あたり 1~30億 が数十 • 1日に約5億レコードを更新 •
移行にはAWSのDatabaseMigrationService(DMS)を利用 … したかった アドテク本部: 移設計画とポイント
• 永遠に終わらないReplication。DMSは過信するなかれ • Aurora Mysql互換の罠。Mysql5.6互換は5.6.10と思うこと • 最大64TB。でもLocalSpaceは1.2TB • Partitionとbinlogはよく考えてから。新機能で非対応多し •
ReadReplicaでも遅延? アドテク本部:移行時と移行後の意外なポイント
まとめ
ご清聴ありがとうございました。