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

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

DeNA_Tech
March 03, 2021

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

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

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

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

DeNA_Tech

March 03, 2021
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. アジェンダ • Mobage とは? • なぜクラウドに移行するのか • オンプレミス / AWS

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

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

    • 1秒の最大リクエスト数 ≒ 10万 req/sec • 物理サーバー数 ≒ 1200台 • 総インスタンス数 ≒ 2000 インスタンス • サーバーの用途の種類 ≒ 400
  4. なぜクラウドに移行するのか • 全社的なクラウド化 ◦ クラウドの利用が必然の新規サービスの増加 ▪ 動画系サービスでトラフィックの増加が予期できないサービス ▪ 世界展開を見越し、レイテンシーを抑えるために海外にサーバーを配置する 必要があるサービス

    ◦ セキュリティの向上 ▪ サービス単位でのネットワークや権限の分離 ▪ 監査ログやネットワークログの網羅性 ◦ オンプレミスの運用をやめ、クラウドに運用リソースを集中して、クラウ ドでの運用の質の向上やコスト最適化を目指すことに • トラフィックが偏りやすいゲーム事業との親和性
  5. オンプレミスの構成 • 物理マシン, もしくは 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 物理マシン
  6. 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
  7. AWS 上でのネットワーク構成 • VPC は 東京リージョンに1つだけ • VPC 内の通信は基本的に許可する •

    subnet ◦ availability zone を 3つ利用して可用性を担保 ◦ public subnet と private subnet を使い分ける ▪ この2つの subnet はセキュリティ観点で使い分けることが一般的 ▪ mobage では別観点で使い分けたので後ほど紹介します
  8. 開発環境を構築 + テスト • OS を CentOS -> Ubuntu 18

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

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

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

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

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

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

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

    全サーバー共通のセットアップ (user 作成, ldap, ntpd など) httpd の設定 MySQL の設定 app A のデプロイ app B のデプロイ データベースのリストア レプリケーション設定 監視ツールへの組み入み サービスへの組み込み (ALB の Listener への追加など) これらを一括して行うツールも開発
  16. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ
  17. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ
  18. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ
  19. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ
  20. オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica

    DB replica webサーバー SQL: 数十 ms 軽い SQL クエリを実行すると・・・ SQL: 数 ms
  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. マイグレーション ~ 移行中の構成 ~ 東京DC * LoadBalancer など色々割愛しています DB primary

    名古屋DC 専用線 webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ Mobage はかつて、東京のデータセンターと名古屋のデータセンターの両 方を利用し、可用性を高めていた 更新クエリ
  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 1% sp.mbga.jp A オンプレミスの IP 99% Route 53 client 1% 99% Transit Gateway webサーバー DB replica DB primary DB replica webサーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  25. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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 の応答速度は オンプレのものと遜色がないか ?
  26. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ
  27. マイグレーション ~ 移行中の構成 ~ オンプレミス * 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
  28. AWS に移行してよかったこと • サーバーの構築手順のコード化 • サーバー購入後のラッキング /初期設定 • RAID の設定

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

    zone (AZ) ただし 1つの AZ 全体の障害が起きたら mobage は落ちる AWS であればそこから短時間で復旧可能 • データを AZ に分散 / リソース確保の容易さ / クラウド化時の手順整備
  30. Tips - サブネットの選択について - • public subnet = 各インスタンスが Global

    IP を持ちインター ネットに直接疎通可能なサブネット • private subnet = インターネットからは隠蔽され、疎通する には NAT Gateway を介する必要があるサブネット
  31. Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet private

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

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

    subnet 不可 private subnet には後述するようなデメリットもあり、 private subnet だけにはできない => であれば public subnet を多用し、別のレイヤー (security group) でキチンと制御する
  34. Tips - サブネットの選択について - • private subnet のデメリット ◦ インターネットへの通信費用がほぼ2倍になる

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

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

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

    Ubuntu: /bin/sh = dash shebang を #!/bin/sh から #!/bin/bash に置換 すればいいのでは?
  38. 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 で違う
  39. 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 とするように変更
  40. 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 で行われ ているので一定のリスクあり 今のところ、とくに問題は起きていない
  41. Tips - エフェメラルポートの枯渇 • エフェメラルポート ≒ TCP の Active Open

    時に利用する 1024 ~ 65535 の ポート • およそ 65000 個しかない • OS の 標準の設定だと 1度使ったポートは 最低でも 60秒間は利用できない • 60秒で 65000回以上、同一サーバーに接続するワークロードでは エフェメラ ルポートの枯渇により、新規TCP接続が張れなくなる ◦ batch が都度 Memcached に接続する場合など
  42. 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) 再利用条件