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 Oﬃce 
DeNA 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 Network
Mobile
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
aﬃliated
with,
endorsed
or
sponsored
by

Chef
Inc.

キャパシティ管理
11

キャパシティ管理
サーバからの各種情報をﬂuentdで集める
• サーバの各種メトリクス(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
⁃ stackprof
15

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
それぞれ

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



...
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

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()
<-‐

[2]
mainloop()
<-‐

[1]
<main>()
<-‐
def mainloop()
while true do
main_proc(2, "dummy_arg")
end
end
def main_proc(interval, dummy)
sleep(interval)
end
mainloop()

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_indiﬀerent_access

118399

(9.2%)

62081

(4.8%)

JSON::Schema.add_indiﬀerent_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

オンプレミスとクラウド
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

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

VPC
各サービス

のVPC
VPC

peering
on-‐premise
VPN

connec8on

まとめ
•DeNAがオンプレミスでこれまで積み重ねてきた運用技術
⁃ 少数のサービスで起こった問題に対して深い理解を目指す
⁃ Perl, Rubyなど、言語処理系のレベルまできちんと調べられる体制を用意
⁃ サーバの性能をきちんと使い切り、効率的運用を目指す
•AWSなどパブリッククラウドの利用
⁃ コスト面ではオンプレミスの方が安い
⁃ 海外向けには有用であり積極的に利用している
35

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

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

More Related Content

What's hot

Viewers also liked

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

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