「ドラゴンコレクション」システム運用の最前線

KONAMIの「ドラゴンコレクション」システム運用の最前線というセミナーに行ってきた。
http://shoukai.type.jp/news/konami_seminar.html

KONAMIはやっぱコンシューマーとかアーケードとか、Cとかに強いイメージがあったけど、やはりWEB関連も普通につよいみたい。
まぁ技術ってそういうもんか。
ドラコレは特に特別な感じではなくベーシックな構成みたいだ。

あと、名刺を余裕もって所持していったつもりだけど最後の方足らなかった。
こういうスキルはまだ全然ないなと思った。

箇条書きのメモをのせとく。

– ドラゴンコレクション
— ソーシャルカードゲームのパイオニア

– 超高トラフィック
— ピーク時秒間httpリクエストxxxxxreq/sec(PHPの動的ページのみ)
— サーバxxx台で運用

– 技術
— CentOS5.5
— Apache2
— PHP5 + APC
— MySQL
— memcached
— いたって普通です
— スケールアウトさせてるよ

– サーバはクラウドですか?
— 開始時はクラウド
— トラフィック増加で・・・
—- DISK I/Oが不安定
—– (相乗りしてるサービスがいた)
—- 内部ネットワークのトラフィックの限界がわからない
—- クラウドのメンテナンスに都合をあわせる必要あり
— パフォーマンスが良い悪いではなく、「不安定」なのが問題
—- 自分たちでは制御/解決できない
— 昨年夏に専有環境に移行

– システムの引っ越し
— いかにメンテ時間を短くするかが課題
— WEBサーバはプログラムを置くだけ
— 問題はDB
—- 旧環境から新環境にレプリケーションさせておく
—– レプリケーション専用のMaster/Slaveサーバを用意
—– 引っ越し後しばらくは新環境から旧環境にレプリケーションしてた
—— 旧環境から新環境でなにか失敗していても、旧環境がマスターデータになりうるため

– 5秒問題
— レスポンスを5秒以内に返してねというアレ
— 瞬間的なトラフィックの限界
— PHPの処理が5秒以上かかりそうだったら「再度ページ開いてね」というメッセージを返す
—- set_time_limit() => PHPのプロセス時間のみ
—– setitimer()でITIMER_PROFを使っているものをITIMER_REALに変更した
—– シグナルセーフでなくなるというリスクがある

– パケロス
— いろいろなプログラムでレイテンシが悪化してた
— プログラムに法則がないので悩んだ
— よく見ると全部9秒かかってる
— WEBサーバ→DBサーバのTCP接続に問題があった
— SYNをロストしてた
— スイッチのキューでパケットがあふれてた
— 監視していたが瞬間的なものにはなかなか気づけなかった
— RTOの変更で解消
— 3秒→1秒

– トラフィックのピーク時間
— 平日
— 08:00
— 11:30-12:00
— 22:00-22:30
— 休日
— 常に高め

– シグナルセーフでなくなって起こった障害などは
— Apacheがたまにhangupする

– NoSQLを利用しない理由は
— 運用で最初に使ってなかった
— 後から導入するのが難しかった
— 複数のミドルウェアを使うとインフラ担当が管理できなくなる規模になる

– テーブルの数を教えてください
— 詳細な数は今わからないが、ユーザデータは8系統で水平分割

– 1チーム何人ですか?
— 教えられない
— イベント開発ラインは複数ある

Posted in 勉強会.

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください