denaインフラの今とこれから - 今編 -

Copyright (C) DeNA Co.,Ltd. All Rights Reserved.

DeNA TechCon 2016

DeNAインフラの今とこれから - 今編 -

Jan 29, 2016

Tomoya KABE Gr. 2, IT Platform Dept, System Head OfficeDeNA Co., Ltd.


$me->describe

⁃ 加辺友也 a.k.a. @limitusus

⁃ 2012/04新卒入社

⁃ 所属: IT基盤部

⁃ 一貫してサーバインフラ周りを担当

⁃ よく見ているミドルウェア

• Apache, nginx, MySQL, Redis, memcached

⁃ よく使っている言語

• Perl, C, Python, (x86)

2


前半で話すこと⁃ DeNAインフラ概況

⁃ サーバ構築の話

⁃ キャパシティ管理

⁃ 障害対応/プロファイリングツール

⁃ オンプレミスとクラウド

3


DeNAインフラ概況

4


DeNAインフラ体制

5

IT基盤部

1G 2G NetworkMobile Service

Cura8on YDB

HealthCare EC IPPF

Mobage PF OpenPF Game

AutoMo8ve

Network

インフラを担当する部署は1箇所

全事業部横断で担当し知見を共有している

infosys


サーバ概要⁃ サーバ数: 4000+

⁃ DRしているので実際の必要台数は1/2

⁃ AWSも一部サービスで利用

⁃ コモディティサーバを利用

⁃ ネットワークトラフィック

⁃ 13Gbps⁃ コストを意識した運用

⁃ サーバ1台あたりの性能を可能な限り使い切る

6


サーバ構築の話

7


mbgaclone⁃ オンプレミス用サーバコピーツール

⁃ AWSでのAMIからinstanceを作るものに近いイメージ

⁃ 実装は各vendor用Management Interface + PXE + anaconda + データコピー + 補助スクリプト

⁃ P2V, P2P, V2V, V2P いずれにも対応

⁃ (Hardware) RAID構成も自動で実施

8


mbgaclone⁃ 利用イメージ

⁃ server01のディスク内容をserver02にコピー & RAIDを1+0に設定

⁃ コピーした後でコピー前～コピー後にdeployされたコードを改めてdeployして本番に投入するだけ

9

# mbgaclone -‐from server01 -‐to server02 -‐raid 10


chef

⁃ chefの導入自体は最早目新しくないが

⁃ 数多くのサービスに

⁃ 既存の運用ツール・体制を踏襲しつつ

利用するための工夫をしている

⁃ Base Cookbook + Application Cookbook + Environment Cookbook構成

⁃ nodeごとの設定はサーバ情報DB(既存)から自動で生成

10

The Chef™ Mark and Chef Logo are either registered trademarks/service marks or trademarks/ service marks of Chef, in the United States and other countries and are used with Chef Inc's permission. We are not affiliated with, endorsed or sponsored by

Chef Inc.


キャパシティ管理

11


キャパシティ管理サーバからの各種情報をfluentdで集める

• サーバの各種メトリクス(CPU etc.)

• リクエスト数

• レスポンスサイズ

Elasticsearchに送る→kibanaで見る

12

Elas8csearch is a trademark of Elas8csearch BV, registered in the U.S. and in other countries. Kibana is a trademark of Elas8csearch BV, registered in the U.S. and in other countries.

外側:ゲームID

内側:API名


キャパシティ管理とは別に…

⁃ これと別にESにクエリ投げて日時のレポートを送信

⁃ エラー数・種類も集計しているのでトラブルシューティングも楽になる

13

ある1週間の時系列エラー数

(PVに応じたエラー数)


障害対応/プロファイリングツール

14


障害対応/プロファイリングツールがんばっても障害は起きる

起きたときの原因調査のためのツールを揃えている

⁃ Perl用

⁃ perlstack

⁃ gdbperl

⁃ phs

⁃ NYTProf

⁃ Ruby用

⁃ gdbruby

⁃ stackprof15


Sample app

#!perl

sub main_proc {

my ($int) = @_;

print `date`;

sleep $int;

}

sub mainloop {

while (1) {

main_proc(1, "dummy_argument");

}

}

mainloop();

16


Perl用 1/4 - perlstack

⁃ 実行中PerlプロセスのPerl stackを取得して出力してくれるツール

⁃ 実行イメージ

⁃ 実装: ptraceでプロセスにアタッチして情報を取得してくる

⁃ 本番動作中の全プロセスにアタッチしても性能低下は見えない程度

⁃ 一部サーバで常時取得しロギングしている17

$ sudo perlstack 29146 29146 /home/kabe/daemon.pl:17 /home/kabe/daemon.pl:10 /home/kabe/daemon.pl:9 /home/kabe/daemon.pl:20

それぞれ sleep()

main_proc() while loop mainloop() が対応


典型的なWeb Appでのperlstack例⁃ アクセスが少ない時間帯⁃ 多数のworkerがaccept()を呼べている=余裕のある状態

18

351,402,434,494,537,1079,1112,1176,1271,1314,1349,1498,1585,1625,1656,1710,1751,1798,1834,1845,2378,2408,2458,2507,2541,2585,2614,2649,2737,2766,2857,2889,2954,2997,3509,3546,3680,32486,32514,32547,32593,32622,32652,32716,32745 /home/game/fcgi/index_smart.fcgi:37 /home/game/fcgi/index_smart.fcgi:35 /home/game/fcgi/index_smart.fcgi:24 ...

accept()を呼んでいる箇所

⁃ DBへのアクセスが集中するような時間帯⁃ DBへのアクセス箇所にプロセスが集中してくる⁃ ひどくなると障害となる3072,3106,3148,3193,3224,3733,3768,3819,3867,3896,3940,3969,4002,4093,4125,4163,4263,4294 /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-‐linux-‐thread-‐mul8/DBD/mysql.pm:149 /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-‐linux-‐thread-‐mul8/DBI.pm:654 /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-‐linux-‐thread-‐mul8/DBI.pm:722 ...

DBアクセス

多くのプロセス


Perl用 2/4 - gdbperl

⁃ 実行中Perlプロセス or core のPerl stack, C stackを出力するツール

⁃ Perlの引数も取得できる(そのときの @_ なので変更されていなければ)

⁃ https://github.com/ahiguti/gdbperl

⁃ 実装: gdbでアタッチ→Perlデータ構造をCレベルで辿ってPerlレベルのスタックを出力

* gdbでアタッチしているため少し遅い

- バッチプロセスが止まってしまったなど

- 今さら遅くなっても関係ない

- 具体的な引数など詳細な調査をしたい

といったケースで有効

19

https://github.com/ahiguti/gdbperl


gdbperl実行例

20

$ sudo gdbperl.pl 29146 ... c_backtrace: #0 0x0000003b318ab140 in __nanosleep_nocancel () from /lib64/libc.so.6 ... #6 0x000000000040181c in main ()

perl_cur_op: /home/kabe/daemon.pl:17(main)

perl_backtrace: [3] /home/kabe/daemon.pl:10(main) -> main::main_proc ARGS: (1, "dummy_argument") [2] /home/kabe/daemon.pl:9(main) -> (loop) [1] /home/kabe/daemon.pl:20(main) -> main::mainloop ARGS: ()

PIDを引数指定

引数が見える


Perl用 3/4 - phs

⁃ webapp workerにおけるメモリ消費の原因を探るために開発

⁃ 一般に「どこでメモリの大量消費があったか」を事後に知ることは困難

⁃ メモリをダンプしてデータ構造を調べるのも大変…⁃ デプロイ差分がわかれば手掛かりになるがデプロイが日に何度もある⁃ 特定のユーザでのみ肥大化するデータ構造もある

⁃ →実行時にメモリ消費のログを取得しておき後から分析できるようにする

⁃ 実装: LD_PRELOADでmallocその他メモリ管理部分の関数を上書く

21

a(); q = malloc(100); b();

libcのmalloc()

void* malloc(size_t sz) { orig_malloc = dlopen(..., "malloc"); p = orig_malloc(sz); バックトレースを保存

return p; }

LD_PRELOAD=phs.so

Perlなどのアプリケーション


phsで出力するログ2種類のログが出力されている

⁃ 短時間で大量のヒープ拡張/縮小を検知した時(EXTEND/SHRINK)

• →Perl/C stacktraceおよびREQUEST_URI

⁃ プロセス終了時(STAT)

⁃ 各コード箇所が消費しているPerlオブジェクトのヒープ消費量

⁃ 「X:32→Y:33→Z:50 で 300バイト消費している」といった情報が得られる

ログが巨大なので工夫が必要

22


phsの出力例(その1)

EXTENDのログ

PHS: EXTEND now=1453362911.604974 cur=11290858 prev=7000000 u=1938144768,864768 blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al):359;/home/game/pm/Cache/Memcached/Redundant.pm:51;...とても長いので省略...:37;/home/game/script/infra/fcgi/mobage_fcgi_starter.pl:143 REQUEST_URI=/XXX?YYY=ZZZ

•ヒープサイズ 7,000,000→11,290,858 に増加したことを検知した様子

23


phsの出力例(その2)...

PHS: /.../Battle.pm:853;/.../Controller.pm:36;/.../Main.pm:947 32 1 168

PHS: /.../Battle.pm:854;/.../Controller.pm:36;/...Main.pm:947 464 10 536



...

⁃ 同じコード箇所でも複数のログに分かれて出力される場合がある

⁃ 人間が読むには巨大すぎる(数分で1万行を越える)

24

Main.pm:947→Controller.pm:36→Battle.pm:853

確保された領域が32バイト


phs その2 のログをまとめる⁃ コード箇所ごとに消費メモリサイズをまとめればそれは役に立つ

⁃ sortすればだいたい怪しい箇所を示してくれる

⁃ phs_summary /path/to/phs_1453362846_17871.log.20160121

⁃ おおよそキャッシュ生成やDBアクセス、レンダリングにヒープを確保しているが、本当に見るべきポイントはリクエスト処理部分

25

34772344 TOTAL _exit 12977604 .../Storable.pm:363;/.../Redundant.pm:51;/.../Cache/GameMd.pm:219 3518056 .../Storable.pm:359;/.../Redundant.pm:51;/.../Cache/GameMd.pm:219 1841736 .../Storable.pm:363;/.../Redundant.pm:51;/.../Cache/Game.pm:165 1441784 /.../DBI.pm:2056;/.../DBD/mysql.pm:793;/.../DBI.pm:1641 538560 /.../Text/Xslate.pm:504;/.../Xslate.pm:91;/.../Response.pm:565 382155 /.../Xslate.pm:101;/.../Response.pm:565;/.../Response.pm:577 379164 .../Storable.pm:363;/.../Memcached.pm:13;/.../Cache2.pm:15 347445 /.../Cache/Memcached/Fast.pm:584;/.../Redundant.pm:30;/.../MA.pm:242 311346 /.../Cache/Memcached/Fast.pm:584;/.../MA.pm:247;/.../MA.pm:186


Perl用 4/4 - NYTProf

⁃ Perlでは定番の高性能プロファイラ

⁃ 性能問題は多くの場合これを見て解決する

⁃ プロファイラのポリシー

⁃ 各サーバ群(ゲーム/API/etc.)に1台ずつ仕掛ける

⁃ 性能劣化があるので全部には仕掛けない

⁃ 複数workerあっても一部プロセスにのみ仕掛ける(PIDを見て調整)

⁃ ログが出過ぎても困る

⁃ 1時間ごとに集計バッチを走らせてアーカイブ化しておく

26


HTML化したNYTProf開発者も簡単にこれを閲覧できる仕組みを用意している

27


Ruby用 1/2 - gdbruby

⁃ 社内初のRubyによる構築案件に伴い開発

⁃ https://github.com/gunyarakun/gdbruby

⁃ 内容・機能ともにだいたいgdbperlと同じ

⁃ 実行イメージ

28

$ sudo ./gdbruby 8861 c_backtrace: #0 0x00007ff9f5p075b in pthread_cond_8medwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 ... #12 0x00007ff9f640594b in main (argc=2, argv=0x7fff6c237138) at main.c:36

ruby_backtrace: [4] sleep() <-‐ /home/kabe/daemon.rb:10 [3] main_proc() <-‐ /home/kabe/daemon.rb:10 [2] mainloop() <-‐ /home/kabe/daemon.rb:5 [1] <main>() <-‐ /home/kabe/daemon.rb:13

def mainloop() while true do main_proc(2, "dummy_arg") end end

def main_proc(interval, dummy) sleep(interval) end

mainloop()

https://github.com/gunyarakun/gdbruby


Ruby用 2/2 - stackprof

⁃ Rubyで現時点でおそらく一番高性能なプロファイラ

⁃ https://github.com/tmm1/stackprof

⁃ 各サーバ群に1台ずつ、一部プロセスで常時取得

⁃ sinatra/rails workerの一部でのみstackprofが動くようにしている

⁃ ほぼNYTProfで実施していたのと同じポリシーで運用できている

29

================================== Mode: cpu(1000) Samples: 1292141 (0.49% miss rate) GC: 184769 (14.30%) ================================== TOTAL (pct) SAMPLES (pct) FRAME 68455 (5.3%) 68455 (5.3%) block in JSON::Schema.add_indifferent_access 118399 (9.2%) 62081 (4.8%) JSON::Schema.add_indifferent_access 293253 (22.7%) 60676 (4.7%) Ac8veSupport::JSON::Encoding::JSONGemEncoder#jsonify 55684 (4.3%) 54697 (4.2%) block in Sequel::Mysql2::Database#_execute 86674 (6.7%) 54318 (4.2%) JSON#generate 71681 (5.5%) 51126 (4.0%) block in Sequel::Mysql2::Dataset#fetch_rows 219461 (17.0%) 37656 (2.9%) block in Hash#as_json

https://github.com/tmm1/stackprof


オンプレミスとクラウド

30


オンプレミスとクラウド⁃ 現時点では(まだ)オンプレミスの方が安い

⁃ 案件によって一部でパブリッククラウドを利用している

⁃ マネージドサービスはあまり利用していない

⁃ 使っているところもある

⁃ 主に海外向け = 遅延が気になる

⁃ AWSの利用が多い

⁃ GCPも一部利用

⁃ AWSを使っていて大変なところも見えてきた

31

⁃ 費用分離のためAWSのアカウントを大量に作成している

⁃ それぞれのアカウントのためにawscliでAPIを叩くのも大変

⁃ STS AssumeRoleというAPIでroleを切り替えてAPIを実行できる


AWSのアカウントが多い

32

親アカウント子アカウント


AWSの権限管理を楽にする⁃ miamというツールがある

⁃ https://github.com/winebarrel/miam

⁃ 各AWSアカウントのIAM権限をRuby DSLにそれぞれdumpしてgitで管理

⁃ 権限設定はPull requestにより依頼/実施

⁃ STS AssumeRoleで発行されたセッショントークンにも対応しているので複数アカウントのIAM権限管理を簡単に実施できる

33

miam

https://github.com/winebarrel/miam


VPN + VPC peering活用によるハイブリッド構成⁃ AWS上にアカウント/VPCが別々の多くのサービス⁃ 管理DBはオンプレのものと共通にしたい⁃ 監視サーバなどはAWS上でいいが共有したい→一部をオンプレに持つハイブリッド構成

34

共通機能

VPC

各サービス

のVPC

VPC peering

on-‐premise

VPN connec8on


まとめ•DeNAがオンプレミスでこれまで積み重ねてきた運用技術

⁃ 少数のサービスで起こった問題に対して深い理解を目指す

⁃ Perl, Rubyなど、言語処理系のレベルまできちんと調べられる体制を用意

⁃ サーバの性能をきちんと使い切り、効率的運用を目指す

•AWSなどパブリッククラウドの利用

⁃ コスト面ではオンプレミスの方が安い

⁃ 海外向けには有用であり積極的に利用している

35


ご清聴ありがとうございました

36

denaインフラの今とこれから - 今編 -

Technology