Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

自己紹介: 貴田 喬博 所属 ● システム本部IT統括部IT基盤部第二グループ 経歴 ● 2013年 新卒 DeNA 入社 ● インフラエンジニア 8年目

Slide 3

Slide 3 text

アジェンダ ● Mobage とは? ● なぜクラウドに移行するのか ● オンプレミス / AWS 上でのシステム構成 ● 移行の流れ ● AWS に移行してよかったこと ● 今後のチャレンジ ● Tips

Slide 4

Slide 4 text

Mobage とは? ~ サービス紹介 ~ ● 2006 年から続いているゲーム プラットフォーム ● パートナー企業によるゲーム ● DeNA の内製ゲーム ● 着せ替えアバターや 日記、 サークルといったSNS

Slide 5

Slide 5 text

Mobage とは? ~ サービス紹介 ~ ● コイン消費額 ≒ 年間 560億円 ● １秒の最大リクエスト数 ≒ 10万 req/sec ● 物理サーバー数 ≒ 1200台 ● 総インスタンス数 ≒ 2000 インスタンス ● サーバーの用途の種類 ≒ 400

Slide 6

Slide 6 text

なぜクラウドに移行するのか ● オンプレミス環境の老朽化 ● 全社的なクラウド化 ● トラフィックが偏りやすいゲーム事業との親和性

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

なぜクラウドに移行するのか ● 全社的なクラウド化 ○ クラウドの利用が必然の新規サービスの増加 ■ 動画系サービスでトラフィックの増加が予期できないサービス ■ 世界展開を見越し、レイテンシーを抑えるために海外にサーバーを配置する 必要があるサービス ○ セキュリティの向上 ■ サービス単位でのネットワークや権限の分離 ■ 監査ログやネットワークログの網羅性 ○ オンプレミスの運用をやめ、クラウドに運用リソースを集中して、クラウ ドでの運用の質の向上やコスト最適化を目指すことに ● トラフィックが偏りやすいゲーム事業との親和性

Slide 9

Slide 9 text

オンプレミスの構成 ● 物理マシン, もしくは 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 物理マシン

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

AWS 上でのネットワーク構成 ● VPC は 東京リージョンに1つだけ ● VPC 内の通信は基本的に許可する ● subnet ○ availability zone を 3つ利用して可用性を担保 ○ public subnet と private subnet を使い分ける ■ この2つの subnet はセキュリティ観点で使い分けることが一般的 ■ mobage では別観点で使い分けたので後ほど紹介します

Slide 12

Slide 12 text

移行の流れ ● 開発環境を構築 + テスト ● 本番サーバーの構築 ● マイグレーション

Slide 13

Slide 13 text

開発環境を構築 + テスト ● OS を CentOS -> Ubuntu 18 に変更 ● オンプレで用いていたLB(Viprion) から ELB に ● サーバーの構築手順を整理/コード化 ● CI による自動テスト + 人力による動作確認

Slide 14

Slide 14 text

Ubuntu化: とあるアプリの一例 ● 10年以上前の system Perl で動いていた ○ => Ubuntu 上で動く perlbrew にビルドし直し ● perl module を社内でパッケージングした rpm でインストールしていた ○ その数 400 以上... ○ 古い OS に入っている特定バージョンのミドルウェアに依存したモジュー ルのビルド... ○ XS(perl の C拡張) の一部が 32bit 環境依存... ○ コンパイラのバージョン差異によるビルドエラー... 古いシステムのOSを移行する難しさ

Slide 15

Slide 15 text

本番サーバーの構築 ● 構築対象は ○ サーバーの種類: 400 ○ インスタンス数: 2000 ○ 中には構築方法や用途が不明のサーバーも ■ コードを読む, プロセスツリーを見る, トラフィックを見 る, といった泥臭いことをして 1つ１つ解明し構築手 順を紐解いていく ● サーバーの構築と、サービスへの組み込みを自動化

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ

Slide 22

Slide 22 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ

Slide 23

Slide 23 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ

Slide 24

Slide 24 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

オンプレミス * LoadBalancer など色々割愛しています AWS Transit Gateway webサーバー DB replica DB replica webサーバー SQL: 数十 ms 軽い SQL クエリを実行すると・・・ SQL: 数 ms

Slide 29

Slide 29 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ

Slide 32

Slide 32 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ

Slide 33

Slide 33 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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 の応答速度は オンプレのものと遜色がないか ?

Slide 34

Slide 34 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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サーバー 更新クエリ レプリケーション 参照クエリ 参照クエリ 更新クエリ

Slide 35

Slide 35 text

マイグレーション ~ 移行中の構成 ~ オンプレミス * 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

Slide 36

Slide 36 text

AWS に移行してよかったこと

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

AWS に移行してよかったこと ● サーバーの構築手順のコード化 ● サーバー購入後のラッキング /初期設定 ● RAID の設定 ● kickstart による OS install ● etc ... OS install ● ロードバランサーAPIの自前実装 ● グローバルIPの管理 ● etc ... NW 設定 AWS API

Slide 39

Slide 39 text

AWS に移行してよかったこと ● 可用性の向上 オンプレ: 1つの DC 😁AWS: 3つの availability zone (AZ) ただし 1つの AZ 全体の障害が起きたら mobage は落ちる AWS であればそこから短時間で復旧可能 ● データを AZ に分散 / リソース確保の容易さ / クラウド化時の手順整備

Slide 40

Slide 40 text

AWS に移行してよかったこと ● ゲームの大きなイベントに備えていくらでもサーバーが増やせる安心 感 ○ オンプレ時代「大きなイベントがあるならサーバー増やすから数ヶ月前 に教えてね」 ● 物理サーバーの管理からの開放

Slide 41

Slide 41 text

今後のチャレンジ ~ コストコントロール ~ ● 他のDeNA サービスで導入済みの仕組み ○ オートスケーリング ○ spot instance の活用 ● アプリケーションチューニング

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Tips - サブネットの選択について - ● 一般的には必要なセキュリティレベルを考慮して選択される ○ web などの秘匿性の低いコンポーネント -> public subnet ○ DB など秘匿性の高いコンポーネント -> private subnet

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

Tips - サブネットの選択について - インターネット webサーバー DBサーバー public subnet 不可 (security group)

Slide 48

Slide 48 text

Tips - サブネットの選択について - ● private subnet のデメリット ○ インターネットへの通信費用がほぼ2倍になる ■ 分析のため BigQuery にデータを送るようなサーバーでは使いづらい ○ インターネット通信の src IP が NAT gateway の IP に集約される ■ mail サーバーのように src IP を分散させる必要があるサーバーでは使えな い ■ (src IP が 集約できることはメリットになる面もある) ○ インターネット通信への秒間の新規接続数に制限がある ■ 外部サーバーに proxy するようなケースでは使えない Mobage では 原則 public subnet を利用 / src IP を集約したい場合のみ private subnet を選択

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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 で違う

Slide 53

Slide 53 text

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 とするように変更

Slide 54

Slide 54 text

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 で行われ ているので一定のリスクあり 今のところ、とくに問題は起きていない

Slide 55

Slide 55 text

Tips - エフェメラルポートの枯渇 ● エフェメラルポート ≒ TCP の Active Open 時に利用する 1024 ~ 65535 の ポート ● およそ 65000 個しかない ● OS の 標準の設定だと 1度使ったポートは 最低でも 60秒間は利用できない ● 60秒で 65000回以上、同一サーバーに接続するワークロードでは エフェメラ ルポートの枯渇により、新規TCP接続が張れなくなる ○ batch が都度 Memcached に接続する場合など

Slide 56

Slide 56 text

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) 再利用条件

Slide 57

Slide 57 text

最後に ● DeNA は近日中にオンプレミス上のほぼすべてのサービ スをクラウドに移行予定です ● 移行したばかりで荒削りな部分が多く、コストコント ロールもまだ徹底できていません ● 大規模サービスの運用改善やコストコントロールに興味 がある人がいればぜひお声がけください！

Slide 58

Slide 58 text

No content