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

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

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

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

Transcript

1. Mobageのオンプレミスから AWSへの移行 貴田 喬博
2. 自己紹介: 貴田 喬博 所属 • システム本部IT統括部IT基盤部第二グループ 経歴 • 2013年 新卒 DeNA 入社 • インフラエンジニア 8年目
3. アジェンダ • Mobage とは? • なぜクラウドに移行するのか • オンプレミス / AWS 上でのシステム構成 • 移行の流れ • AWS に移行してよかったこと • 今後のチャレンジ • Tips
4. Mobage とは? ~ サービス紹介 ~ • 2006 年から続いているゲーム プラットフォーム • パートナー企業によるゲーム • DeNA の内製ゲーム • 着せ替えアバターや 日記、 サークルといったSNS
5. Mobage とは? ~ サービス紹介 ~ • コイン消費額 ≒ 年間 560億円 • １秒の最大リクエスト数 ≒ 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つ１つ解明し構築手 順を紐解いていく • サーバーの構築と、サービスへの組み込みを自動化
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 は近日中にオンプレミス上のほぼすべてのサービ スをクラウドに移行予定です • 移行したばかりで荒削りな部分が多く、コストコント ロールもまだ徹底できていません • 大規模サービスの運用改善やコストコントロールに興味 がある人がいればぜひお声がけください！