このエントリーをはてなブックマークに追加

Category Archives: インフラg

「Amazon Web Services 負荷試験入門」を読んだ

こんにちは。インフラグループ マネージャーの黒木です。

以前弊社のまべ☆てっくにてご登壇いただいた仲川樽八さん共著のAWS負荷試験本が出たらしいという噂を聞きましたので、早速弊社でも購入して読ませていただきました。

Amazon Web Services 負荷試験入門

こちらですね。
タイトルこそAWSに寄っていますが、中身は他の環境でも使える普遍的な内容がほとんどです。
負荷試験の入門本としてとても良いものだと思いましたので、いくつかおすすめポイントや感想などを(勝手に)書かせていただこうかと思います。

 

・最初の失敗事例がホントにありそうな感じでやばい

読みながら「うわーこれ知らないとマジでやりそう……」って口から出ちゃいました。
たいへんリアルなアンチパターンの塊で、後の章のケーススタディとは対照的に、やってはいけないことが詰まってます。

・負荷をかける側のボトルネックあるある

攻撃側の環境によって詰まりやすいところがいろいろ書かれていて
疑うべきところがわかりやすくよかったです。負荷をかける側もほんとよく詰まるんですよね……。

・想定されるボトルネックがマジで実践的

実際のゲームの負荷試験の現場を何度も見てきましたが、
そこでぶち当たる壁はほぼ網羅されていたと言っても過言ではありません。
この本に書いてある箇所を一通り疑えば、大抵の負荷試験はクリアできるでしょう。

・AWSについてももちろん詳しい

AWS独自で必要となる緩和申請などについても詳細に書かれていて良いです。
他の環境でも似たような手続きが必要になることがありますね。

・ケーススタディがめっちゃ丁寧

10章のケーススタディがめちゃくちゃ丁寧で、どのように負荷試験を進めればよいかが一通り網羅されており
読みながら実際の負荷試験を側で見ているかのような体験ができます。
JMeter以外の負荷ツールを使用した事例もあり、そちらは弊社では経験がないので興味深く読ませていただきました。

 

■まとめ

通して読んだ感想としては、たいへん実践的な一冊だと思いました!
入門という位置付けの書名ですが、既に大規模な負荷試験を多数経験している弊社のようなユーザーでも、
改めて負荷試験時の注意点を再認識すると同時に、チェック項目などの体系化にも役立ちそうだと感じました。

これを読めばその日からバッチリ負荷試験に対応できます!
負荷試験をしたことがない方、負荷試験をする可能性のある方、
これから負荷試験をするという方 読んでおいて損はないどころか得しかない内容です。

 

■最後に

マーベラスでは、ガッツリ負荷試験を行い安心してゲームを世に送り出す仲間を募集しております。
詳しくは採用情報をご覧ください。


PHP7を同時接続25,000/秒、webを36台ならべて負荷計測してみた

●PHP7を、商用環境で使いたい!

さて、PHP7が2015年12月に正式リリースされてから、早4か月が経ちました。
そろそろ安定してきたかな…、と思いつつも、まだまだ商用環境に導入するのは不安だと思います。

「本当にPHP7って高速なの?」
「PHP7って安定して動くの?」

いろいろな不安があるかと思います。
何しろ、PHP5からのメジャーバージョンアップですから。
普通に考えたら、まだ時期尚早かもしれません。

でも、やはり使いたい。
なにしろ、PHP5と比較して2倍の速度で動作するというのは、大きな魅力です。

そこで、「本当に商用環境で使えるか」という観点で、「リアルな」検証をしてみたいと思います。

●本当に使える、リアルな計測をしよう!

PHP7はPHP5に比べて、高速に動作するという触れ込みです。
実際に「だいぶ速くなったよ」といった検証結果が多く見受けられます。

しかし「これだ!」という検証内容がなかなか見つからないわけです…。

例えば、プログラミングで言うところのハローワールドレベルのものや、単純なコマンドをひたすらループさせたもの等々。
何でもそうですが、ベンチマークで計測した速度と実際に使ってみたときの速度って、結構違いますよね。

とにかくリアルなプログラムで計測したい。
そこで実際に弊社で開発中のアプリケーションを使って負荷試験をしてみました。
しかも、結構な高負荷をかけて。

「安定して動く」プログラムが「安定して動かなくなる」のは、負荷が上がってリソースがひっ迫したときや、並列性が上がったときではないでしょうか。
PHP7自体も勿論プログラムの集合体ですから、問題が発生するとすれば、そういったタイミングと推測できます。

さて、実際に負荷をかけてみました。

●高負荷で計測しよう!

※サーバ構成/ミドルウェアについては、開発中のアプリケーションということでぼかしてあります。お察しください…。

サーバ 台数 CPUコア数 メモリ(GB) 備考
web(APIサーバ) 36 8 16 内訳:34台がPHP5、2台がPHP7。
分散はLVSにより実現(分散方式は単純なラウンドロビン)
DB(master/slave) 3 40 120 -
KVS(memcached/redis) 3 4 16 -

 

ミドルウェア バージョン
php 7.0.4
apache 2.2系
MySQL 5.5系
memcached 1.4.16
redis 2系

 

その他
負荷ツールはjmeterを使用
jmeterからのアクセスは外部ネットワーク経由
jmeterを稼働させるクライアントマシンは25台
jmterシナリオは、実際のアプリケーション操作をシミュレートしている
jmeterはrampupやwaitを入れることで実行タイミングをずらしている(実際のユーザーのプレイ状態に近づけるため)
cactiを使用して各種サーバ負荷を計測
newrelicも使ってみました

 

●計測結果

レスポンスタイム

・newrelicによる計測結果です。
・jmeterからのリクエストを、平均して75msec程度で処理しています。内訳は、以下の通りです。

  • MySQLが10msec程度
  • Memcachedが数msec
  • Redisは一瞬
  • PHPは60msec強(但し、 DB処理等のウエイトも含まれる)

・この辺はアプリケーションの作りによるため、PHP5/PHP7の比較とは直接無関係ですが、アプリケーションの性質を理解するための参考値としてご参照ください。
・ちなみに当該グラフはPHP5のwebサーバにて取得しています。

スループット

・スループットです。webサーバ一台に対して、ページビューで約120/sec程度の負荷がかかっているとご理解ください。
・web台数が36台ですので、ページビューの総計は約4,320/secとなります。
・こちらのグラフも負荷の規模を理解するための参考値とお考えください。

※以下は、web02がPHP5のグラフ、web36がPHP7のグラフとなります。

CPU

・CPU負荷です。コアごとにグラフが分割されていますので100%が最大値となります。
・負荷は全CPUに綺麗に分散されている状態です(つまりどのコアも同程度の負荷)
・PHP5は80%程度のCPU使用率ですが、PHP7は40%程度となります。大きな差ですね。

Load Average

 

・ロードアベレージです。グラフの単位が異なっていることにご注意ください。
・PHP5は15~20程度ですが、PHP7は1以下です。
・jmeterからのリクエストはラウンドロビンにより分散していますので単純に比較はできませんが、同じ処理をするのであれば圧倒的にPHP7の方が軽いということは解ると思います。

コンテキストスイッチ

・コンテキストスイッチ(タスク切り替え)の回数です。
・実運用上あまり問題にならない数値ではありますが、PHP5に比べてPHP7の方が多いことが確認できます。
・並列性を高めることで高速化に寄与する仕組みなのかもしれませんが、掘り下げた調査はしていません(すいません)。

メモリ

・メモリ使用量です。
・一番下の茶色い部分が実メモリ使用量です。その上の肌色の層がキャッシュ、緑の層が空き領域です。
・PHP5が12Gbytes使用しているのに比べ、PHP7は8Gbytes程度です。CPU同様、大きな差ですね。
・PHP7の方がキャッシュ使用量が多いのも、良い意味で期待ができるところです。

参考までにDBのクエリ処理状況

・マスターDBが処理したクエリの状況です。内訳は以下となります。

  • 赤色…select
  • 黄色…insert
  • 緑…update
  • ピンク…その他も加えた総数

(他にdeleteなどもあるが見えない程度)
・秒間で20,000クエリ以上捌いているようなアプリケーションを動かしている、というところから色々と想像を膨らませていただければ幸いです。

その他

以下は、PHP5/PHP7で差が無いグラフです(PHP5のものだけ張ってあります)
トラフィック等は変わらなくて当たり前の数値ではありますが、あくまでも参考ということで…

●使っても大丈夫そう、でも…

負荷計測は約6時間続けましたが、特に大きな問題は発生していません。
安定して動作していたと言える結果でした。

性能面では、特にCPU、メモリについて大きな差が見受けられました。
明らかにPHP7の方が性能が良いと言って間違いないと思います。

今回のテストの場合、それぞれのwebサーバが処理しているページビューの数はほぼ同一ですので、全てのwebサーバをPHP5からPHP7に置き換えた場合、webサーバの台数がかなり削減できると推測されます。

ちなみにコードレベルでのPHP5->PHP7への移行コストは一般的に低いと言われているようですし、実際、今回の負荷計測に使用したアプリについては、かなり移行コストが低かったという事実もあります。

しかし問題は、言語仕様の違いよりもインタプリタ(ライブラリ)の違いにあるのではないでしょうか。

例えばインタプリタ(ライブラリ)内部のバグで、apacheがsegmentation faultで落ちたりすると…
いや、素直に落ちてくれればまだ良いのですが、中途半端に生き残ってクライアントからの接続をacceptできたりする状態だと、障害に繋がる可能性が高くなるわけです。
昔であればライブラリ内部をアセンブラレベルでトレースして、「メモリコピーのときにアライメントがずれて落ちてますよ今すぐ何とかしてくださいよこっちは寝てないんですよ」などとライブラリベンダに文句を付けたりしていたわけですが、
現在はそんな時代でもなく、さらに言えば、そんなことをするくらいならPHPなんか最初から使わないわけです。

つまりは、低コストで安全に使えないと意味がないのです。

PHP7が枯れるまでは大き目のバグfixや、セキュリティ問題の修正等によるアップデートが続くと予測されますので、運用コストの一部として十分に考慮する必要があります。
アップデートによるエンバグも怖いですから、いきなり本番環境のPHPをアップデートするわけにもいかないですしね…。

せっかくサーバ費用を削減しても、運用コストが増えてしまったのでは本末転倒です。
なかなか難しいですね…。


見えないトラフィック~Unicast Flooding~

どうも、ishinoy@インフラです。

クラウドサービスを利用していると、VM上のトラフィックはCactiとかで
取得してますが、物理ホストのトラフィックはわからないですよね?

通常はクラウドサービス会社さんに監視してもらうと思うのですが、
先日、サーバをクラスタ移動したらやけにトラフィック量が多くなっているらしく、
調査したところUnicastFloodingが発生していたというお話しです。
 
UnicastFloodingとは?
 ユニキャストパケットがブロードキャストされ、回線を逼迫させてしまう現象
 
ちょうど、先日参加したセミナーでも、某大手ポータルサイト様の環境で
同様のことが起き、発表されていました。
 
 
えーと、まずは図を見ていただいたほうがわかりやすいですね!
(↓クリックすると拡大)

unicastflooding_1

WebサーバからDBサーバへ通信する際に、
LVSの負荷軽減のためにDR構成にすることは良くあると思うのですが、
DR構成では非対称ルーティングとなります。(行きと帰りの道が異なる)

WebサーバとDBサーバは直接通信することは無いので、
スイッチ02でWebサーバのMACアドレスは学習されることはなく、
スイッチの仕様として、そのようなパケットは全ポートへ転送してしまうのです。
(スイッチ01,02はスタック構成ではない)

もちろん、Webサーバにもパケットは届くので、
サービスとしては一見、問題なく処理しております。

ちなみに、LVSサーバとDBサーバが逆の場合は発生しません。

WebサーバとDBサーバは同じスイッチに接続している上に、
LVSサーバとDBサーバはヘルスチェックで定期的に通信しているので、
スイッチが学習するのです。
 
 
なるほどですね~
 
 
考えられる対策ですが、実はスマートな方法が見つからず、
サーバ規模と運用面を考えて、下記の案2)としています。
 
 
 案1) WebサーバとDBサーバを同じスイッチ配下に置く
    ⇒どこのスイッチ(=クラスタ)にサーバがあるか管理する必要がある上に、
     クラスタ障害時の冗長性も考えると、複雑怪奇です…

 案2) 定期的にPingを打つ
    ⇒Web/DBサーバ間のみでも良いですが、増減設時の漏れを考えると、
     いっそのことサーバは全てスイッチにPingを打つ仕様の方が
     管理面で楽ですかね…

 案3) LVSのDR構成を止めてNAT構成にする
    ⇒そもそもの主旨とずれますが、LVSに負荷がかかるようになるので、
     負荷分散のためにサーバ増加となりコストアップです…
 
 
 
ふと、前職でMSのNLBとCisco機器の仕様の違いで、
スイッチのMACテーブルが学習されずに
通信ができなかった不具合を思い出したのでした。。。
 
それでは 


「ブラウザ三国志」のクラウド導入事例が紹介されました!

どうも、ishinoy@インフラです。

5周年を迎えた「ブラウザ三国志」のサーバリプレースが無事終わり、
クラウド基盤であるフリービット社に導入事例が掲載されましたので紹介します。

https://cloud.freebit.com/cloud/case/marvelous.html

Logo_final_ver


インフラグループの紹介

はじめまして、ishinoy@インフラ と申します!
 
 
「祝!エンジニアブログ開設」ということで、
初回はインフラグループの紹介をしたいと思います!
 
 
 人数: 約10名

 担当タイトル: 約20
   ゲームサーバ以外にも、KPI/ログ/メンバーズサイトや、
   コンシューマ、アミューズメント機器と連携しているサーバもあります。

 サーバ: クラウドサービスを利用(数社)
     基本的に仮想環境上でのLAMP構成です。
     必要に応じて、PrivateCloud/ベアメタルも利用しています。

 運用: MSP会社さんに手伝っていただいています(数社)
 
 
 
「少数精鋭」という訳ではないのですが、既存タイトルの運用はもちろん、
企画チーム・デバッグチーム・開発チーム(社内、社外)と調整しながら
新規タイトルの設計・構築もするので、作業は比較的あります。
 
また、数社のクラウドサービス、MSP会社さんに手伝っていただいているので、
各社の特徴とタイトルに合わせた選択ができ、コスト面でのメリットも
出せているのではないかと思っています。
 
  
~ インフラの仕事に興味がある方は是非! ~
 サーバ構築・運用はもちろん、新規タイトル立上げ時の設計もできますし、
 各部門や業者さんとの調整でマネージメント能力も養えます!