オンプレからAWSへの移設とそのヒント

2016ba6b977a2e6691811fa66d5f4336?s=47 CyberAgent
February 22, 2019

 オンプレからAWSへの移設とそのヒント

サイバーエージェントの技術者(エンジニア・クリエイター)向けカンファレンス『CA BASE CAMP 2019』
オンプレからAWSへの移設とそのヒント

2016ba6b977a2e6691811fa66d5f4336?s=128

CyberAgent

February 22, 2019
Tweet

Transcript

  1. 4.

    ティーマ 2017年2月 内定者アルバイト入社 サイバーエージェント 技術本部 サービスリライアビリティグループ (SRG) 2018年4月 サイバーエージェント新卒入社 SRG配属

    AWS (特にECS、Lambda)、Elasticsearch、Terraform、 Datadogを専門とし、メディアの新規 立ち上げサポート、既存サービスの改善に携わる メディアのTerraform共通化プロジェクト立ち上げ AWA、REQU、タップル誕生、CROSS MEを担当
  2. 7.

    小林 邦明 2012年 CA Advance 中途入社 2013年 サイバーエージェント アドテク本部 移動 Strategic

    Infrastructure Agency Group Solution Architect Team 所属 アドテク本部内で開発される各サービスのインフラ技術 支援を担当 オンプレ、社内クラウド、AWS、GCPと多様な 環境だが、一番好きなのはAWS
  3. 10.

    に移設した理由 • に移設した実績があった ◦ • データセンターの基幹スイッチなどハードウェアの保守切れ ◦ 、セルフィ、アドテク本部 • オンプレを保守運用する人員の確保問題

    ◦ 、セルフィ • サイバーエージェントグループ内の豊富な利用事例 ◦ セルフィ、アドテク本部、タップル • マネージドサービスを導入していきたい、オートスケーリングを利用したい ◦ タップル
  4. 17.

    • マネージドにできるものはマネージドにする ◦ Redis → ElastiCache (Redis) ◦ MySQL →

    RDS (Aurora) • マネージドにできないものはそのまま持っていく ◦ MongoDBそのまま持っていく (各アプリサーバに乗っているmongosをプロキシに使う) ◦ Elasticsearchもそのまま、ALBでアクセスを分散 • Private CloudからAWSデータ層へのアクセスはDirect Connect経由 (途中でmuninとsensuがDatadogにリプレイスされて、 Jenkinsとpostfixが消える) タップル誕生: 移設
  5. 19.

    タップル誕生: 移設 • 構成を大きく変えず、アプリ層をそのまま持っていく ◦ 仮想サーバ → EC2 Instanceとして持っていくだけ ◦

    EC2 Auto Scaling Groupを利用 ◦ haproxy、nginxをALBにリプレイス ◦ 静的コンテンツの配信は、S3+CloudFront • APIアクセスはRoute 53 Traffic Flowで徐々に段階的に流す ◦ xx% でオートスケールでピーク捌けるか? ◦ 問題が起きたらすぐ切り戻せる
  6. 22.

    タップル誕生: 移設 コンテナ化構成、を一旦大まかに • API: ECS EC2 Type • Batch:

    ECS Fargate Type (スケーリング設計簡略化) • MongoDBへのアクセス: mongos専用EC2 Instance x3経由 • ログ周り: Kinesis+Lambda 今後のマイクロサービス化へ…
  7. 24.

    タップル誕生:まとめ • データ層の移行はメンテ入れる • アプリ層はRoute 53 Traffic Flowでオンライン切り替え • スモールスタート

    • 切り戻しが難しいものを最後に持っていく ◦ ただし、パフォーマンスなど、先に解決したい課題があれば、 そこからスタートしても良し • 一気にアーキテクチャを変えない • 小さく進めて「チェックポイント」を作っていく
  8. 25.
  9. 26.

    が展開する事業 音楽 芸能 ヘルス ケア 占い スポーツ ローカ ライズ 占い・芸能・音楽・ヘルスケア・スポーツ・ユーティリティ

    … 様々なジャンルのWebサイト、アプリを提供。 海外アプリのローカライズも実施。
  10. 27.

    移設概要 • 主な移設実施期間 月 月 • 、 で提供している約 サービス ◦

    関連部署は つ ◦ 占い・アーティスト・コンテンツ・課金、整合システム • キャリア課金・クレカ課金あり • の課金システムを統合 • エンジニア主導
  11. 28.

    移設計画と 移設計画 • 決済基盤を構築する 複数環境をマージ • アプリケーションの変更はしない • システム構成の共通化 •

    メンテナンスは、分けて実施 ◦ キャリア決済で最低 回実施 • のサービスの精査、クローズを実施 • エンジニア主導で移設を推進 • 全社朝会やポスターを利用し社内の認知度向上 • 行けるものからどんどん移設 その他Tips • 決済システムに想定外のサービスのログがないか調査 • キャリアは ヶ月前には、サービスクローズ申請手続き • テスト端末は早めに確保して、課金可能額も確 認 • テスト利用時の を コードを印刷して準備 • 打ち合わせ、移設時にホワイトボードを利用 ◦ 進捗と認識を合わせ写真に記録し共有共有 • メンテ時に発生した事象をポスト・イットに書き、対処できる 人にアサイン たくさんあるが、 つだけ紹介
  12. 29.

    メンテナンスは分けて実施 データベース 決済 ウェブアプリケーションに分けて実施 1. AWS Direct Connectを利用し、データベースを先行して移設 2. 決済を移設

    3. ウェブアプリケーションやバッチなどを移設 よかったこと ・複数回実施することで、問題発生時の切り分けがスムーズに!!! ・準備までの作業者のタスクやメンテナンス時の作業がより明確に!!! ・決済切り替えが、 サービス合わせて、 時間で終わることも!!
  13. 32.

    Google Big Query Amazon S3 Fluentd aggregator Fluentd collector container

    Network LoadBalancer ECS Instance Application LoadBalancer DatadogAgent container Dashboard Service container ローカル環境 ECR ECS Instance 共通化した構成
  14. 37.

    セルフィ:システム紹介 • 構成 一般的なウェブアプリケーション アプリケーションサーバ / DB / キャッシュ /

    NAS (共有ストレージ) • データ層 RDB(PostgreSQL / MySQL) 複数系統で合計 4TB くらい NAS NFSでマウント、主にアバター画像など 合計 3TB くらい
  15. 38.

    セルフィ:移設の概要 • 期間 技術選定や調査などを含めて10ヶ月程度 • 使用している主なサービス Route53 / ELB /

    EC2 / ElastiCache / S3 • 今回のスコープで使用を見送ったサービス Amazon Aurora / DMS / EFS (直前で東京リージョンでリリース )
  16. 40.

    セルフィ:移設を振り返って • DMS は素晴らしいけど要検証 一部の DB のテーブル構成に起因して、特定のデータが正常にコピー されず、DB の集約および Aurora

    への移行を断念しました。 大半のケースでは DMS は力を発揮するツールですが、 きちんと事前に検証しましょう。 ※ソース DB 側(移行前の既存環境)のスキーマを変更すればよかったのですが諸々の事情で変更できず。 • 東京リージョンではまだ使えなかったサービス EFS は移設予定日の直前にローンチされるも検証時間不足で断念。
  17. 44.

    • DB1台あたり1TB~10TB • レコード数は1Table あたり 1~30億 が数十 • 1日に約5億レコードを更新 •

    移行にはAWSのDatabaseMigrationService(DMS)を利用 … したかった アドテク本部: 移設計画とポイント
  18. 46.