未分類

「GREEを支える大規模インフラテクノロジー」-GREE Platform Summer Conference 2012

by mukae [2012年8月03日]

,2012/8/12編集部追記
下記、記事についてエンジニアのjovi0608（はてぶID）さんがフォローアップ記事を書いてくださいました。リンクを掲載致します。
http://d.hatena.ne.jp/jovi0608/20120809/1344474864

取締役　執行役員CTO　開発本部長
藤本　真樹氏

2005年6月にGREEに入ってから7年が経ちました。
GREEでは開発全般を見ていて、最近はインフラよりもクライアントの方を見ますが、元々はサーバーサイドよりの人間なので、今回こういう話ができて嬉しいです。

今回のお題でサーバーサイドに関して話してみては？
と言われて、すごく困ってしまった。
何故かというと、大規模サービスを普通にやるテクノロジーのコモディティ化が進んだからです。

１０倍のユーザーが来た時にどうすればいいのかというのは、インターネット上にいっぱい情報が既にあり、それを支えるオープンソースのプロダクトや、クラウドサービスなど解決策がいくつもある。

Agenda

1.Infrastructure for over 100,000,000users
2.Infrastructure for global services
3.Infrastructure for smartphone apps
4.And more

インフラの所で多くのユーザーを捌くのは楽になっている。
Pinterest、Instagramなどはインフラエンジニアがいなくてもあれだけのユーザー、トラフィックを捌けている。

一方で、今までのアーキテクチャを続けていいのかというと、それでは競争力が失われる。
サービスは提供できているが、他社ができていることができなくなったりする。
本当はもっといろいろなことができるのに、クライアントサイドで制限がかかってしまう可能性がある。
今までスタンダードだったことを見直していかなければいけない。

おかげさまで、GREEで多くのユーザー様に利用いただいていて、それを支える技術などは一般的な技術書として存在し、みんなやっていることは同じ。
グローバルにサービスをだしてみてわかってきたことや、アメリカに月に1回いってGoogleやfacebookがどうやって世界中にサービスを提供しているのか情報収集している。

スマートフォンにサービスがシフトしていく中で、一番悩ましいのが100%シフトしてしまうのかというとそうではなくて、前からずっとフィーチャーフォンのアクセスがまだまだあるので一気に変えられるかというと難しい。
インフラは強いが、今あるものを動かし続けながらチャレンジし続けなければいけない。

大規模なトラフィックを捌くというのは、さまざまノウハウが開示されていて、良くも悪くも目新しいものはない。

一方で、そこでどういう競争をしていくかというところで、一人の技術者としてなかなか難しい。

例えばデータが増えましたというと、人手のコストを忘れればRDBMSに負荷がかかればスレーブを活かそう、シャーディングしましょうというのはどこの会社でもやっている。

Basic Strategies

・Sharding
・Preparing basic tech stacks
・Reducing operation costs

運用や障害、変化に対するコストをどう下げるのかということに関しても、コモディティ化が激しいと感じている。

最近、全部スケールを前提に考えるかというとそうではなくて、SSDを使っていて意外に壊れなく台数も増えている。

Sharding

・Still, important
・Not for everything(←SSD,etc)
・GREE Users’ Tables
[ID/Status]
[Profile_1][Profile_2]
[Mail_1][Mail_2]
[Uuid_1][Uuid_2]

GREEのユーザーのテーブルは割りきっていて、
シャーディングしないという前提で、IDとStatusだけを持つテーブルを一つのデータベースに置いておく。
ハードディスクがきつかったらSSDに置く。今年はSSDが600Gや800Gというのがでてきている。

そこにユーザープロフィールをユーザーIDに紐付けてシャーディングしている。
それだけではメールアドレスで検索できないということになるので、転置インデックスもシャーディングしていく。
携帯だとキャリアごとや、端末IDもシャーディングしてユーザーIDを引けるようにする。
10億、20億規模では全然問題ない。目新しい話でもなく普通にできること。
ユーザー100万、1,000万などを持つのが普通な時代に入ってきた。

■Topics
1.Server Dashboard + API
2.Server Configuration Management
3.DNS:Bind/Prim(Original)
4.Load Balancers : LVS/Apache
5.App Servers:Apache/Node+PHP,etc
6.RDBMS:MySQL
7.KVS
8.Large Object Storage
9.Messaging Queue
10. Full Text Search: Solr
11.Monitoring/Alerts

サーバーが100台、200台になってくると、それを管理するダッシュボードは結構大事。

データセンターやネットワークに対峙すると、自分たちで頑張るしかない。
サーバーのインスタンスの管理はダッシュボードでいいが、そこにどういうメタ情報をつけるのかが大事だと思っている。

例えば、デプロイするにもソースコードをどのサーバにデプロイすればいいのか。
一元管理したいので、サーバーのダッシュボードにデータをおいてデプロイするときにAPIを叩いて、そのリストをとってきてデプロイする。

最近ロードバランサーで悩んでいて、Apacheのmod_proxy_balancerはバギーであまりおすすめできない。これからはnginxを使うことをオススメする。

javascriptをサーバーサイドでも使うケースが多くなってきていて、必然的にnode.jsを使うことになるが、大きく３つの問題がある。

１．ひたすらすごい勢いでバージョンアップしているので安定しない。コストを払ってついていく覚悟を持って取り組んでいる。
２．メモリリークがあるので、サーバを起動しっぱなしにするとメモリが食いつぶされる。
３．コードをデプロイしても再起動しないと読み込まれない。

毎回デプロイするときにプロセスを上げなおさないといけない。
node.jsを使う場面では接続をクライアントが持ちっぱなしにしていることが多いので、
せっかくweb socketでチャットをしていてるのに、デプロイのたびに再起動しなくてはいけない。

これで絶対大丈夫という解決策がなくて、node.jsで一番悩んでいる。
これでバッチリ解決するというものがあれば、是非教えて欲しい。

Basic Tech Stacks

1.Server Dashboard+API
⇢meta information is important
2. Load Balancers: LVS/Apache
⇢mod_proxy_balancer is somehow buggy
3. App Servers: Apache/Node+PHP ,etc
　⇢Node.js episodes(updates/leaks/deploy)
4.KVS⇢Network is being bottle neck
5.Messageing Queue
　⇢No de facto standard…
6.Monitoring/Alerts
　⇢Nagios capacity / some know hows
7.Deploy
・・・

KVSに関しては、mongoDBなどいろいろとでています。
GREEでKVS使うとパフォーマンスがすごくでるので、調子に乗って使っていると1Gの回線があっという間に喰い潰される。
特に1エントリーで10kだと、１万qps出てトラフィックがあふれる。
メッセージキューの宿命として、基本的にキューがあふれることが発生するときに人手がかかるのが悩み。

モニタリングでは、最初Nagiosを使っていたが、大体1,000台のサーバーを超えてくるとスケールしなくなってきて、今はオリジナルのシステムを使ってメッセージキューを立てて、アラートが飛んだらメッセージキューに通知させる。

単純にアラート出たら携帯にメール送るのもいいのだが、アラートの量が多くなってくるとフィルタリングの必要性が高まる。
最初の一通目はとにかく早く送って、そのあとは上手くまとめて送っている。

deployはメジャーツールとして、Capistranoがありますが、それこそ2,000台にデプロイするには悩ましい。
いいものが開発できれば、公開したい。0.1秒で全台に配ればいいのか？というと、そういうことではない。

global services

レイテンシなど今は世界中にインスタンスを立てられるので試すと面白い。
意外と東京から時間を食うのはヨーロッパ。
トランジットが２経路あって、ルートを間違うとパケットロスが発生する。

Latency management

・Tokyo + US⇢<150ms
・Impact of latency(RTT)
　・conversion Rate: + n%
　・Need to be sensitive
　　・CDN
　　・Native / Local Storage /HTTP Cache
　　・Less connections (Image/CSS/JS)
・・・

東京とアメリカにサーバを置けば世界中から150msでサービスできる。
どこに置いても、300msみておけばサービスできる。

例えば画面が表示されるまで、0.5秒違うとコンバージョンが数10％変わってくる。
特にブラウザで何か操作している場合はレイテンシ0.2秒表示を速くするということはアプリケーションでもインフラでも大事だと身にしみて感じていること。

解決策としてCDNを使うことや、近いサーバから配信してもらう。

そもそも通信しないでアプリケーションで頑張ってもらう。
HTMLの場合はローカルストレージを使って通信を発生させない。
iOSのsafariだと、同時に張れる接続数が同じドメインだと2か3。

PCの感覚で、CSSを5個とかやっているとそれだけで遅くなる。この辺は、目に見えて成果が変わってくるので大事。