Upgrade to Pro — share decks privately, control downloads, hide ads and more …

MobageのオンプレミスからAWSへの移行【DeNA TechCon 2021】/techcon2021-8

MobageのオンプレミスからAWSへの移行【DeNA TechCon 2021】/techcon2021-8

14年の歴史を持ち、1000台以上の物理サーバーを利用していた Mobage をオンプレミスから AWS へ移行しました。
また、同時に OS を CentOS6 から Ubuntu18 に更新しました。

・長らくオンプレミスで運用してきたサービスをなぜクラウドに移行するのか
・サービスをメンテナンスに入れずに移行をする工夫
・現在の課題やそれについての改善計画

などについて、インフラエンジニアの観点からお話します。

8a84268593355816432ceaf78777d585?s=128

DeNA_Tech

March 03, 2021
Tweet

Transcript

  1. Mobageのオンプレミスから AWSへの移行 貴田 喬博

  2. 自己紹介: 貴田 喬博 所属 • システム本部IT統括部IT基盤部第二グループ 経歴 • 2013年 新卒

    DeNA 入社 • インフラエンジニア 8年目
  3. アジェンダ • Mobage とは? • なぜクラウドに移行するのか • オンプレミス / AWS

    上でのシステム構成 • 移行の流れ • AWS に移行してよかったこと • 今後のチャレンジ • Tips
  4. Mobage とは? ~ サービス紹介 ~ • 2006 年から続いているゲーム プラットフォーム •

    パートナー企業によるゲーム • DeNA の内製ゲーム • 着せ替えアバターや 日記、 サークルといったSNS
  5. Mobage とは? ~ サービス紹介 ~ • コイン消費額 ≒ 年間 560億円

    • 1秒の最大リクエスト数 ≒ 10万 req/sec • 物理サーバー数 ≒ 1200台 • 総インスタンス数 ≒ 2000 インスタンス • サーバーの用途の種類 ≒ 400
  6. なぜクラウドに移行するのか • オンプレミス環境の老朽化 • 全社的なクラウド化 • トラフィックが偏りやすいゲーム事業との親和性

  7. なぜクラウドに移行するのか • オンプレミス環境の老朽化 ◦ 長期間使っているサーバーが大半 ◦ 故障率も年々上昇 ◦ 物理サーバーをリプレイスするか、クラウドに移る かの2択に差し掛かっていた

  8. なぜクラウドに移行するのか • 全社的なクラウド化 ◦ クラウドの利用が必然の新規サービスの増加 ▪ 動画系サービスでトラフィックの増加が予期できないサービス ▪ 世界展開を見越し、レイテンシーを抑えるために海外にサーバーを配置する 必要があるサービス

    ◦ セキュリティの向上 ▪ サービス単位でのネットワークや権限の分離 ▪ 監査ログやネットワークログの網羅性 ◦ オンプレミスの運用をやめ、クラウドに運用リソースを集中して、クラウ ドでの運用の質の向上やコスト最適化を目指すことに • トラフィックが偏りやすいゲーム事業との親和性
  9. オンプレミスの構成 • 物理マシン, もしくは KVM の Linux を利用 • httpd

    ◦ Apache, Nginx, lighttpd • application の利用言語 ◦ Perl, Ruby, Java, etc.. • データストア ◦ MySQL, Memcached, Redis • etc ◦ Mroonga, Senna, Postfix... クライアント CDN ロードバランサー(Viprion) Apache Nginx Perl Ruby Java MySQL Memcached Redis Mroonga Senna Postfix 物理マシン
  10. AWS 上でのシステム構成 • 変更点は・・・ ◦ ロードバランサーが ELB に ◦ 物理マシン,

    KVM を EC2 に • なるべくオンプレと近い構成 ◦ 移行工数を最小限に ◦ コスト面でも EC2 に分がある • AWS 上で利用しているサービスは ◦ EC2, VPC, S3, Route 53 程度 クライアント CDN ロードバランサー(ELB) Apache Nginx Perl Ruby Java MySQL Memcached Redis Mroonga Senna Postfix EC2
  11. AWS 上でのネットワーク構成 • VPC は 東京リージョンに1つだけ • VPC 内の通信は基本的に許可する •

    subnet ◦ availability zone を 3つ利用して可用性を担保 ◦ public subnet と private subnet を使い分ける ▪ この2つの subnet はセキュリティ観点で使い分けることが一般的 ▪ mobage では別観点で使い分けたので後ほど紹介します
  12. 移行の流れ • 開発環境を構築 + テスト • 本番サーバーの構築 • マイグレーション

  13. 開発環境を構築 + テスト • OS を CentOS -> Ubuntu 18

    に変更 • オンプレで用いていたLB(Viprion) から ELB に • サーバーの構築手順を整理/コード化 • CI による自動テスト + 人力による動作確認
  14. Ubuntu化: とあるアプリの一例 • 10年以上前の system Perl で動いていた ◦ => Ubuntu

    上で動く perlbrew にビルドし直し • perl module を社内でパッケージングした rpm でインストールしていた ◦ その数 400 以上... ◦ 古い OS に入っている特定バージョンのミドルウェアに依存したモジュー ルのビルド... ◦ XS(perl の C拡張) の一部が 32bit 環境依存... ◦ コンパイラのバージョン差異によるビルドエラー... 古いシステムのOSを移行する難しさ
  15. 本番サーバーの構築 • 構築対象は ◦ サーバーの種類: 400 ◦ インスタンス数: 2000 ◦

    中には構築方法や用途が不明のサーバーも ▪ コードを読む, プロセスツリーを見る, トラフィックを見 る, といった泥臭いことをして 1つ1つ解明し構築手 順を紐解いていく • サーバーの構築と、サービスへの組み込みを自動化
  16. 本番サーバーの構築 EC2 instance の作成, security group の割当など web1 web2 MySQL

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など)
  17. 本番サーバーの構築 EC2 instance の作成, security group の割当など web1 web2 MySQL

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など) Chef
  18. 本番サーバーの構築 EC2 instance の作成, security group の割当など web1 web2 MySQL

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など) Nagios + 内製ツール
  19. 本番サーバーの構築 EC2 instance の作成, security group の割当など web1 web2 MySQL

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など) 内製ツール
  20. 本番サーバーの構築 EC2 instance の作成, security group の割当など web1 web2 MySQL

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など) これらを一括して行うツールも開発
  21. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ
  22. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ
  23. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ
  24. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ
  25. オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica

    DB replica webサーバー RTT(ping): < 1ms
  26. オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica

    DB replica webサーバー RTT(ping): < 1ms (同一AZ) ~ 1ms (別AZ)
  27. オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica

    DB replica webサーバー RTT(ping): ~ 5ms
  28. オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica

    DB replica webサーバー SQL: 数十 ms 軽い SQL クエリを実行すると・・・ SQL: 数 ms
  29. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  30. マイグレーション ~ 移行中の構成 ~ 東京DC * LoadBalancer など色々割愛しています DB primary

    名古屋DC 専用線 webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ Mobage はかつて、東京のデータセンターと名古屋のデータセンターの両 方を利用し、可用性を高めていた 更新クエリ
  31. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 0% sp.mbga.jp A オンプレミスの IP 100% Route 53 client 0% 100% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  32. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 1% sp.mbga.jp A オンプレミスの IP 99% Route 53 client 1% 99% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  33. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 1% sp.mbga.jp A オンプレミスの IP 99% Route 53 client 1% 99% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ - web サーバーが正常にレスポンスを返しているか ? - AWS の DB replica の応答速度は オンプレのものと遜色がないか ?
  34. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 100% sp.mbga.jp A オンプレミスの IP 0% Route 53 client 100% 0% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  35. マイグレーション ~ 移行中の構成 ~ オンプレミス * LoadBalancer など色々割愛しています DB primary

    AWS sp.mbga.jp A AWS の IP 100% sp.mbga.jp A オンプレミスの IP 0% Route 53 client 100% 0% Transit Gateway webサーバー DB replica DB replica DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ DB master MasterHA for MySQL
  36. AWS に移行してよかったこと

  37. AWS に移行してよかったこと • 用途や構築手順の分からなかったサーバー群の解明/整理

  38. AWS に移行してよかったこと • サーバーの構築手順のコード化 • サーバー購入後のラッキング /初期設定 • RAID の設定

    • kickstart による OS install • etc ... OS install • ロードバランサーAPIの自前実装 • グローバルIPの管理 • etc ... NW 設定 AWS API
  39. AWS に移行してよかったこと • 可用性の向上 オンプレ: 1つの DC 😁AWS: 3つの availability

    zone (AZ) ただし 1つの AZ 全体の障害が起きたら mobage は落ちる AWS であればそこから短時間で復旧可能 • データを AZ に分散 / リソース確保の容易さ / クラウド化時の手順整備
  40. AWS に移行してよかったこと • ゲームの大きなイベントに備えていくらでもサーバーが増やせる安心 感 ◦ オンプレ時代「大きなイベントがあるならサーバー増やすから数ヶ月前 に教えてね」 • 物理サーバーの管理からの開放

  41. 今後のチャレンジ ~ コストコントロール ~ • 他のDeNA サービスで導入済みの仕組み ◦ オートスケーリング ◦

    spot instance の活用 • アプリケーションチューニング
  42. Tips - サブネットの選択について - • public subnet = 各インスタンスが Global

    IP を持ちインター ネットに直接疎通可能なサブネット • private subnet = インターネットからは隠蔽され、疎通する には NAT Gateway を介する必要があるサブネット
  43. Tips - サブネットの選択について - • 一般的には必要なセキュリティレベルを考慮して選択される ◦ web などの秘匿性の低いコンポーネント ->

    public subnet ◦ DB など秘匿性の高いコンポーネント -> private subnet
  44. Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet private

    subnet 不可 ここが疎通できないから “セキュア” だ というのが一般的
  45. Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet private

    subnet 不可 システムの中でもっともセキュリティの低い部分 = システム全体のセキュリティレベル • web サーバーに侵入されてしまえば、そこから DB サーバーに到達可能 特定の箇所だけを過剰に守ってもあまり意味がない
  46. Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet private

    subnet 不可 private subnet には後述するようなデメリットもあり、 private subnet だけにはできない => であれば public subnet を多用し、別のレイヤー (security group) でキチンと制御する
  47. Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet 不可

    (security group)
  48. Tips - サブネットの選択について - • private subnet のデメリット ◦ インターネットへの通信費用がほぼ2倍になる

    ▪ 分析のため BigQuery にデータを送るようなサーバーでは使いづらい ◦ インターネット通信の src IP が NAT gateway の IP に集約される ▪ mail サーバーのように src IP を分散させる必要があるサーバーでは使えな い ▪ (src IP が 集約できることはメリットになる面もある) ◦ インターネット通信への秒間の新規接続数に制限がある ▪ 外部サーバーに proxy するようなケースでは使えない Mobage では 原則 public subnet を利用 / src IP を集約したい場合のみ private subnet を選択
  49. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash POSIX 互換を目指した 軽量でシンプルな シェル bash の拡張機能は使えない (例えば echo hoge &> /dev/null の &> も bash の拡張機能)
  50. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash POSIX 互換を目指した 軽量でシンプルな シェル bash の拡張機能は使えない (例えば echo hoge &> /dev/null の &> も bash の拡張機能) bash では動くが、 dash では動かないスクリプトが多数存在
  51. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash shebang を #!/bin/sh から #!/bin/bash に置換 すればいいのでは?
  52. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash shebang を #!/bin/sh から #!/bin/bash に置換 すればいいのでは? • 😢 Perl の system() は /bash/sh -c 経由になるケースがある (Ruby, Python でも同様) bash 用に書かれたシェルスクリプトを dash 用に改修が必要 • 😢 sh -c のプロセスツリー bash / dash で違う
  53. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash shebang を #!/bin/sh から #!/bin/bash に置換 すればいいのでは? • 😢 Perl の system() は /bash/sh -c 経由になるケースがある (Ruby, Python でも同様) bash 用に書かれたシェルスクリプトを dash 用に改修が必要 • 😢 sh -c のプロセスツリー bash / dash で違う Ubuntu でも /bin/sh = bash とするように変更
  54. Tips - CentOS -> Ubuntu 移行 CentOS: /bin/sh = bash

    Ubuntu: /bin/sh = dash shebang を #!/bin/sh から #!/bin/bash に置換 すればいいのでは? • 😢 Perl の system() は /bash/sh -c 経由になるケースがある (Ruby, Python でも同様) bash 用に書かれたシェルスクリプトを dash 用に改修が必要 • 😢 sh -c のプロセスツリー bash / dash で違う Ubuntu でも /bin/sh = bash とするように変更 • dash で動くスクリプトが bash でも動く保証はない • Ubuntu の標準パッケージのテストなどは dash で行われ ているので一定のリスクあり 今のところ、とくに問題は起きていない
  55. Tips - エフェメラルポートの枯渇 • エフェメラルポート ≒ TCP の Active Open

    時に利用する 1024 ~ 65535 の ポート • およそ 65000 個しかない • OS の 標準の設定だと 1度使ったポートは 最低でも 60秒間は利用できない • 60秒で 65000回以上、同一サーバーに接続するワークロードでは エフェメラ ルポートの枯渇により、新規TCP接続が張れなくなる ◦ batch が都度 Memcached に接続する場合など
  56. Tips - エフェメラルポートの枯渇 • net.ipv4.tcp_tw_reuse: エフェメラルポートをすぐに再利用するオプション • Ubuntu 18 ではデフォルト有効なので安心していたら・・・負荷テスト中に枯渇

    • tcp_tw_reuse を有効にするには、あわせて net.ipv4.tcp_timestamps が必要 batch server (Active Open) Memcached (Passive Open) tcp_tw_reuse = ON (デフォルト ON) tcp_timestamps = ON (デフォルト OFF) tcp_timestamps = ON (デフォルト OFF) 再利用条件
  57. 最後に • DeNA は近日中にオンプレミス上のほぼすべてのサービ スをクラウドに移行予定です • 移行したばかりで荒削りな部分が多く、コストコント ロールもまだ徹底できていません • 大規模サービスの運用改善やコストコントロールに興味

    がある人がいればぜひお声がけください!
  58. None