スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー(MySQL)を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。
スマホアプリ「モンスターストライク」のサーバー負荷は、年末年始に1年のピークを迎えます。2018年元旦のサーバー負荷に立ち向かうために実施した対策の一例として、データベースサーバー(MySQL)を安全に水平分割した事例を紹介します。見積もりから計画、実施に至るまでを時系列で振り返ります。
Redisは多彩なデータ構造をもつ1インメモリDBであり、昨今のWebアプリケーションのデータストアの一つとして、広く利用されている。 しかし、一方で、性能改善のための手法を体系的にまとめた資料が見当たらないと感じていた。 実際、最初にCPU負荷が問題になったときにどうしたものかと悩み、調査と試行錯誤を繰り返した。 そこで、この記事では、自分の経験を基に、RedisサーバのCPU負荷対策を「CPU負荷削減」「スケールアップ」「スケールアウト」に分類し、パターンとしてまとめる。 背景 RedisのCPU負荷対策パターン CPU負荷削減 multiコマンド Redisパイプライニング Luaスクリプティング Redisモジュール(夢) スケールアップ スケールアウト 参照用スレーブ 垂直分割 水平分割 Redis Clusterによる水平分割 その他 スライド資料 あとがき 参考資料 背景 R
こんばんは、 @matsumotoryです。 hb.matsumoto-r.jp 上記エントリにおいて、プロセスの大量メモリ確保に伴うページテーブルサイズとベージテーブルエントリ数の肥大化によるcloneやexecveの性能劣化とCPU使用時間の専有問題、および、それらの解決方法についてシステムコールレベルで確認しました。 そこで今回は、システムコールやそのカーネル内部の処理の性能、というよりは、より実践的な環境であるApache httpdとmod_cgiを用いて、phpinfo()を実行するだけのCGIに対してベンチマークをかけた時にどれぐらいCPUのidleが空くか、システムCPUの使用量が変わるかを、前回示した解決方法の1つであるHugePagesを使うかどうかの観点で比較してみましょう。 特定条件下のWebサーバ環境のシステムCPUに起因する高負荷問題から、システムコールやカーネ
こんにちは。グリフォンでインフラエンジニアをしている徳田です。 日々運用しているインフラの改善や新規ゲームのインフラ設計などを行っているのですが、先日、グリフォンで4年運用しているブラウザゲーム「不良遊戯 シャッフル・ザ・カード」(以下、不良遊戯)のインフラをGoogle Cloud Platform(以下、GCP)へ移設しました。今回は、その時の経緯や設計、行った作業やTipsについてご紹介します。 経緯 大まかな経緯として、 インフラコストの削減 パフォーマンスの向上 インフラ環境の整備 技術的な挑戦 がありました。しかし、事の発端は私がGCPを使いたい・試してみたいというなんとも自分勝手な提案だったのですが(笑)。 「インフラコストの削減」と「パフォーマンスの向上」については、不良遊戯をリリースしたのが2014年の5月で3年経っており、リリース時に比べVMのコア単価が安く、CPU性能
メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ...バグだらけのWebアプリケーションを使ってバグを理解するJavaバグ脆弱性トラブルシューティングjconsole 概要 Webアプリケーションの開発や保守をしていると、いろいろなバグに遭遇します。メモリリーク、デッドロック、リダイレクトループ、JVMクラッシュ等々、バグは様々です。こういったバグは、実際にコードを書いて、実行・再現させてツールで解析してみると理解が深まります。 ということで、いろいろなバグを実装したWebアプリケーションをつくってみました。現時点では、以下を簡単に再現できます。 メモリリーク (Javaヒープ領域) メモリリーク (Permanent領域) メモリリーク (Cヒープ領域) デッドロック (Java) デッドロック (SQL) 完了しないプロセスの待機 無限ループ リダイレクトループ JVM
2017/02/16 Developers Summit 2017
大人気TBSドラマ、「逃げるは恥だが役に立つ」でも話題になったインフラエンジニアという言葉ですが、今ではインターネットインフラを知らないまま開発をするのも難しい状況になっています。クラウドが一般化されたからといって単にリソースの調達が簡単になっただけで、つまりハードウェアの知識が無くても何とかやっていけるようになっただけであり、インフラの知識が要らなくなったなどということは全くなく、むしろdevopsの掛け声とともに、ソフトウェア開発者にインフラを見なければならない新たな責務が課せられたという、なかなか痺れる状況なのだろうと思います。 そういった中で、先日のさくらインターネットのAdvent Calendar最終日に「いまさら聞けないLinuxとメモリの基礎&vmstatの詳しい使い方」という記事を書かせて頂きましたが、今回はLinuxサーバの「負荷」と、ロードアベレージに関して、掘り下げ
結構前に作っていたんですが、いろいろと忙しくてブログに書くタイミングを失していたので年末のタイミングで紹介。 TL;DR GoReplayを利用して、Production環境のリクエストを複製し、Stagins環境、開発環境に投げる仕組みを作った インフラ構成の大きな変更無しで、手軽にProduction環境の実リクエストを複製し、開発、動作検証ができるようになった 2016年の弊社サービスのDocker化や、インフラ構成の大幅な変更、ミドルウェアのアップデート、アプリの改修時のバグ事前検知と事故防止に大いに役に立った GoReplayの説明 GoReplay Goで書かれており、バイナリを設置し、オプションを指定し実行するだけで動作する アプリが稼働しているサーバで動く。(例えばNginx+Railsが稼働しているサーバで一緒にGoReplayを動かす感じ。) libpcap を利用して
今年、稼働中のサービスであるはてなブログのデプロイ方法を新しい方式へ無事故で移行し、従来と比べて約6倍速くデプロイできるようになりました。 この記事では、安全にデプロイ方式を変えたプロセスを順を追って紹介します。 はてなブログと継続的デリバリー デプロイが遅い 複雑なデプロイ設定 デプロイのテストを書く ボトルネックの発見、そして pull 型から push 型のデプロイへ 新デプロイへの移行 結果 まとめ はてなブログと継続的デリバリー はてなブログは1日あたり平均して1.02回デプロイを行っています。これは土日を除いた週5日の営業日に対する平均です。ざっくりとした算出で、祝日は考慮していません。5月と9月の祝日を含めるともう少し多くなるかもしれません。 また、原則として休日の前日にはデプロイしないことになっています。もしもデプロイした変更にバグがあった場合、休日が明けてから対応するか、
ウェブオペレーションエンジニアの id:y_uuki です。2016年度のウェブオペレーションエンジニアの新卒研修を紹介します。 今年はウェブオペレーションエンジニアとして2名(id:masayoshi id:taketo957)が新卒として入社しました。若手のインフラ系エンジニアが少ないと言われる昨今で、もともと7人のインフラチームに2人も新卒が加わることはなかなか珍しいのではないでしょうか。 今年の新卒エンジニアは 2016年度はてな新人エンジニア研修を行いました - Hatena Developer Blog のエントリで紹介した新人エンジニア研修の後に、チームに配属されました。通例であれば、チーム配属後はOJTという名目で即実戦投入されます。しかし、今回は、OJTの前段に2週間程度の研修期間を設けてみました。 研修の動機 ウェブオペレーションエンジニアは、一般的なコンピュータサイエ
YAPC::Asia Hachioji 2016 mid in Shinagawa 2016-07-03 Yusuke Wada a.k.a. yusukebe
国内有数のWebサービスを手がけるYahoo! JAPANは、その毎秒100万リクエストという膨大なトラフィックを支える大規模なインフラチームを抱えています。そのうち画像などを配信するプライベートCDNでは、オープンソースのATS(Apache Traffic Server)をキャッシュサーバーに採用し、本家OSSプロジェクトでの開発にも積極的に参加しています。OSSのコミッタを業務とするYahoo! JAPANのプラットフォーム開発エンジニアのお二人と、はてなからインフラチームとMackerelのエンジニアが参加し、インフラエンジニアの働き方について座談会形式でお聞きしました。 座談会出席者は、(上写真、左より)ヤフー株式会社の小柴薫居さんと北條正和さん、はてなの坪内佑樹(id:y_uuki)と松木雅幸(id:Songmu)。構成はITジャーナリストの星暁雄。記事の最後にプレゼントのお知
3.12(土) に五反田のRettyオフィスで開催されたRetty Tech Cafe #5 に行ってきました。 http://connpass.com/event/26679/ タイムテーブルはこんな感じ。今回のテーマは "SRE" ということで、自分が一休.comで担当している業務に近しいものがあったので興味を持って参加されていただきました。 # Speaker Title 1 Retty CTO 樽石さん(@taru0216) Retty SRE のご紹介〜 元 SRE エンジニアによる SRE の概要と Retty での適用事例について 〜 2 All About 鈴木さん (@jp_taku2) オールアバウトをオンプレミスで支える技術 3 mercari 長野さん (@kazeburo) メルカリにおける、継続的なアプリケーションの改善を支える技術 4 Retty teemuさ
dots. Conference Spring 2016 ゲーム開発の裏側 http://eventdots.jp/event/580344
少し前に,Facebookのロードバランサが話題になっていた. blog.stanaka.org このエントリを読んで,各種Webサービス事業者がどういったロードバランスアーキテクチャを採用しているのか気になったので調べてみた. ざっくり検索した限りだと,Microsoft, CloudFlareの事例が見つかったので,Facebookの例も併せてまとめてみた. アーキテクチャ部分に注目してまとめたので,マネジメント方法や実装方法,ロードバランス以外の機能や最適化手法といった部分の詳細には触れないことにする. 事例1: Microsoft Azure 'Ananta' MicrosoftのAzureで採用されている(いた?)ロードバランサのアーキテクチャは,下記の論文が詳しい. Parveen Patel et al., Ananta: cloud scale load balancing
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く