Upload
taimei-omata
View
1.532
Download
0
Embed Size (px)
DESCRIPTION
AWSとTriFortCloudの比較。 インフラエンジニアの仕事の説明。
Citation preview
AWS vs TriFortクラウド選びのポイント
VS
自己紹介
<経歴>
日本ヒューレット・パッカードや NTTコミュニケーションズなど
の大手 ITベンダーで技術職を担当し、システム運用やネットワー
ク構築などのノウハウを習得。
その後、 2009年にソーシャルゲーム開発において業界トップクラ
スであり、東証 JASDAQに上場している CROOZ株式会社に参画し、
同年 6月に取締役に就任。
翌年 5月同社技術統括担当執行役員に就任。 CTOとして大規模
WEBサービスの開発に携わる。
2012年 6月に退任、 2012年 8月に大竹とともにトライフォート
を設立し現在代表取締役 Co-Founder/CTOを務める。
代表取締役 Co-Founder/CTO 小俣泰明twitter @taimeidrive
facebook: taimei omata フォローしてね^^
目次
1. インフラ領域の作業とは?2. AWSと TriFort Cloudのコスト比較3. AWSと TriFort Cloudのサーバースペック比較4. AWSと TriFort Cloudの保守サポート比較5. AWSと TriFort Cloudの監視比較6. AWSと TriFort Cloudのネットワーク比較7. AWSの不安なポイント
インフラの作業の確認
• 電力確保、無停電装置、免震台など環境の用意 (コロケーション )
• ネットワーク環境をつなぐ• システム設計、サイジング• サーバーの選定購入、キッティング• ネットワーク機器選定• ラック配置、ケーブリング• ネットワーク設計 (IPセグメント、冗長構成 )
• OSインストール• ミドルウェアの設定、チューニング• ドメインの取得、設定• プログラミングの本番アップのシステム• 監視設計• 導入後の障害対応
AWSの範囲
• 電力確保、無停電装置、免震台など環境の用意• ネットワーク環境をつなぐ• システム設計、サイジング• サーバーの選定購入、キッティング• ネットワーク機器選定• ラック配置、ケーブリング• ネットワーク設計 (IPセグメント、冗長構成 )
• OSインストール (一部標準構成のみ )
• ミドルウェアの設定、チューニング• ドメインの取得、設定• プログラミングの本番アップのシステム• 監視設計• 導入後の障害対応
AWSであっても赤字の部分を対応するエンジニアが必要!
TriFortの範囲
• 電力確保、無停電装置、免震台など環境の用意• ネットワーク環境をつなぐ• システム設計、サイジング• サーバーの選定購入、キッティング• ネットワーク機器選定• ラック配置、ケーブリング• ネットワーク設計 (IPセグメント、冗長構成 )
• OSインストール• ミドルウェアの設定、チューニング• ドメインの取得、設定• プログラミングの本番アップのシステム• 監視設計• 導入後の障害対応
TriFortクラウドは全て対応したものを提供します。
AWS、 TriFortクラウド比較表:費用
例:ソーシャルゲーム (AppStore/ Google Playランク 50位前後の某タイトル )の規模の場合
AWS Trifort
サーバ費 7,431,332 4,000,000
回線費 ※平均 50Mbps時のコストで算出
318,000(1Mbpsあたり ¥6,360)
250,000(1Mbpsあたり ¥5,000)
保守サポート 570,770 700,000
計 8,320,102 4,950,000
※AWSの費用計算には、無料利用枠割引分は除いています
※回線費は弊社運用中のソーシャルゲーム (AppStore/ Google Playランク 50位前後の某タイトル )の実際のトラフィック量から算出
サーバーコスト(内訳)
AWS 単価 (1台あたり )
Trifort 単価 (1台あたり )
Webサーバ
c3.8xlarge 4台 CPU: Intel Xeon E5-2670 v2 (Ivy Bridge) コア数: 32 memory: 60GB HDD: SSD 132GB
151,132
Webサーバー 4台 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge) コア数: 32 memory: 64GB HDD: SSD 132GB
150,000
DBサーバ
RDS db.r2.8xlarge 10台 プロビジョンド IOPS 20,000 CPU:(非公開) コア数: 32 memory: 60GB HDD: SSD
583,578
DBサーバー 5台 IOPS 80,000 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge)コア数: 32 memory: 256GB HDD: ioDrive2 750GB
440,000
Cacheサーバ ElastiCache cache.m2.4xlarge 4台 CPU:(非公開) コア数: 8 memory: 68GB
96,624
Cacheサーバ 4台 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge)コア数: 32 Memory: 64GB
150,000
画像サーバ
c3.8xlarge 2台 CPU: Intel Xeon E5-2670 v2 (Ivy Bridge) コア数: 32 memory: 60GB HDD: SSD
151,132
画像サーバ 2台 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge)コア数: 32 Memory: 64GB HDD: SSD
150,000
バッチサーバ
c3.8xlarge 1台 CPU: Intel Xeon E5-2670 v2 (Ivy Bridge) コア数: 32 memory: 60GB HDD: SSD
151,132
バッチサーバ 1台 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge)コア数: 32 Memory: 64GB HDD: SSD
150,000
ステージングサーバ
c3.8xlarge 1台 CPU: Intel Xeon E5-2670 v2 (Ivy Bridge) コア数: 32 memory: 60GB HDD: SSD
151,132
ステージングサーバ 1台 CPU: Intel Xeon CPU E5-2650 v2 @ 2.60GHz (Ivy Bridge)コア数: 32 Memory: 64GB HDD: SSD
150,000
比較表:保守サポート
AWS (ビジネスレベル )
Trifort (プラン A: 24時間サポート ※ 4)
Trifort (プラン B: インフラコンサルテング 24時間サポート ※ 4)
ハードウェア障害対応 ○ ○ ○
ネットワーク障害対応 △ ※1 ○ ○
ミドルウェア障害対応 × ○ ○
セキュリティパッチ対応 × ※2 ○ ○
ミドルウェア導入支援 × ○ ○
障害時メッセンジャー自動通知サービス (StarTalk)
× × ○
プログラムエラー監視 × × ○
MySQLスローログ検出サポート × × ○
MySQLレプリケーション遅延検出サポート
× × ○
SQLチューニングサービス × × ○
過去データ分析サービス × × ○
システムコンサルティング (最適なサービス構成の提案 )
× ※3 × ○
月額費用
ビジネスサポート 10,000~ AWS月額使用量に応じた従量課金
400,000 700,000
※1 AWSネットワークに起因するものであれば対応。 VPC内部ネットワークの設定上の問題などはユーザが対応する必要有り ※2 EC2インスタンスの場合。 RDSなど PaaSソリューションについては対応 ※3 エンタープライズレベルでは対応
※4 プラン A 初動保証: 12時間以内 プラン B 初動保証:リアルタイム
補足: AWSのサポート費用の算出方法(ビジネスサポート )
いずれか大きい方 100 USD または - 以下の計算結果 - 月額 AWS 使用料のうち最初の 0 – 10,000 USD の 10% 月額 AWS 使用料のうち 10,000 – 80,000 USD に対しては 7% 月額 AWS 使用料のうち 80,000 – 250,000 USD に対しては 5% 月額 AWS 使用料のうち 250,000 USD を超える分に対しては 3% 貼り付け元<https://aws.amazon.com/jp/premiumsupport/?nc1=h_l2_cc>
比較表:監視 監視 AWS TriFort
CPU使用率 ○ ○
Disk読み取り操作の数 ○ ○
Disk書き込み操作の数 ○ ○
Disk読み取りバイト数 ○ ○
Disk書き込みバイト数 ○ ○
ネットワーク受信バイト数 ○ ○
ネットワーク送信バイト数 ○ ○
ロードアベレージ × ※2 ○
メモリ使用率 × ※2 ○
ディスク使用率 × ※2 ○
障害通知:メール △ ※3 ○
障害通知: StarTalk ※1 × ○
監視データの保存期間 14日 永続
※1「 Startalk」は Trifort社のコミュケーションツールです
※2 カスタム設定で対応することもできますが、実装が必要、かつ追加従量課金がかかります
※3 デフォルトでは何も設定されないので、エンジニアが個別に設定する必要があります
【参考】 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html
宣伝:『スタートーク』アラートメールサービス
http://startalk.trifort.jp/dev/
メールだと誰が対応したのかわからない?
気づきにくい。スタートークはLINEのようなサービスでアラートをメッ
セージグループに飛ばすことが出来ます。
ネットワーク比較表(ロードバランサー、内部トラフィック)
AWS Trifort
インターネットトラフィック 約 130 Mbps ばらつきあり 約 330Mbps ほぼ安定
内部サーバー間トラフィック 約 220 Mbps ばらつきあり 約 940Mbps ほぼ安定
パフォーマンス面(処理方式 )
L7プロキシとして動作 このため DSR構成とくらべて負荷がかかる。レスポンスタイムに影響
L3の DSR方式
バースト的なアクセス (大規模公告や、大規模イベントへの負荷対応)
段階的スケールのため処理に時間がかかる (予め対応させるには pre-warming申請が必要 )
処理可能
ロードバランサー振り分け方式
(仕様公開されていないがおそらく )ラウンドロビン ? 少なくともインテリジェンスなバランシングはできない
重み付け振り分けが可能
AWS使用する上で不安に思う点 (1 )
・内部サーバー間通信が重い点 このためサーバースペックのボトルネックよりも、ネットワークボトルネックのため、Webサーバーなどをスケールアウトすることになる。・ネットワーク構築の知識やサーバセキュリティの知識はある程度必要 ・同じ物理リソースを共有している他インスタンスが重いと、それに引っ張られてスペック出ないことがある (ここが実は重要なボトルネックのため、サーバー台数を増やす要因になるケースが非常に多い) →インスタンス停止→再起動すれば別の物理リソースに割り当てられるようにはなるが とはいえ、本番機系統では簡単に停止できないケースも
・ AWSの監視( CloudWatch)データは過去 2週間分しかさかのぼって確認できない →それより前のデータが必要となると自前でMRTG/Zabbix等システムを入れる必要がある ・ AWS EC2のデフォルトの監視項目は、サーバ内部のリソース状況( LoadAverage、メモリ使用率等)が取れない →カスタムメトリクスの実装が必要、かつ従量課金かかる
AWS使用する上で不安に思う点 (2)
・インターネット側通信もボトルネックとなる・インテリジェンスなバランシングが構成できないL7プロキシとして動作:ロードバランサー (ELB)は配下のインスタンスに対して重み付けして振り分けができない →厳密には違うらしいが (仕様が公開されてないのでわからない )利用してみた感じ、ほぼ単純なラウンドロビン
AWSの LoadBlancer(ELB)は、実態はプロキシサーバのようなもので ELBの外側と内側は別々の TCPコネクションになります。 参考:ブログ:debiancdn
総合比較
柔軟性
○ネット上からすぐにサーバーを増減できる( API処理に寄る自動化まで可能)
△高スペックサーバーを用意し、そもそもスケールアウトせずに対応できるシステムを提供
※まもなくネット上でのインスタンス増減もリリース予定!
スペックコスト
△低スペックサーバーから高スペックサーバーまで用意可能台数が多くなりがちでコストが高くなる。
○超高スペックサーバーが用意可能CPU、 IOPS が高いので、少ないサーバ数で構成を組みやすい。 ※まもなく安価版もリリース予定!
サポートエンジニア
△AWS好きインフラエンジニアが必要
○ハードだけでなくインフラエンジニアもクラウド化できる。 (インフラエンジニア無しで対応可能 )
サポートコンサルテン
グ
△システムサイジングや設計レベルの問い合わせはこなせない。
○大規模トラフィックに対応するノウハウを提供。サイジングにも協力
まとめ
TriFortCloudのターゲット
・プログラマーだけですぐに始められる点
・インフラエンジニア無しでソーシャル系サービスを作りたい会社、個人。
・コストを抑えたい会社。
・ 0.1秒のパフォーマンス(レスポンスタイム)の改善に意識が高い会社
是非、 AWSのみならず TriFortCloudをご検討ください!
Git/Subversionプランからオープン!(フルマネージド )
https://cloud.trifort.jp/
安価版も順次リリース予定!
TriFort:ミニマムサーバー (予定 ) 2,000円 /月
AWS:マイクロサーバー 2,000円 /月
AWS:ラージ(一般的なWebServices) 15,000/月
次頁以下 補足資料
以下補足:ネットワークベンチマーク測定
• 使用ツール nuttcp http://www.nuttcp.net/nuttcp/Welcome%20Page.html • 結果 実サーバ実スイッチによる構成の方が勝る nuttcpツールでは約 5倍速い Ping応答は約 10倍速い
※インターネット回線に向けては測定箇所やネットの使用状況に応じて値が変わる為、どちらが良いかの測定は難しい。
TriFort内部ネットワークベンチマーク測定有明 IDC web17 > web18測定# nuttcp -v -i1 x.x.x.119nuttcp-t: v6.1.2: socketnuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> x.x.x.119nuttcp-t: time limit = 10.00 secondsnuttcp-t: connect to x.x.x.119 with mss=1448, RTT=0.230 msnuttcp-t: send window size = 524288, receive window size = 524288nuttcp-t: available send window = 393216, available receive window = 393216nuttcp-r: v6.1.2: socketnuttcp-r: buflen=65536, nstream=1, port=5001 tcpnuttcp-r: interval reporting every 1.00 secondnuttcp-r: accept from x.x.x.118nuttcp-r: send window size = 524288, receive window size = 524288nuttcp-r: available send window = 393216, available receive window = 393216 112.1250 MB / 1.00 sec = 940.5699 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6203 Mbps 0 retrans 112.1875 MB / 1.00 sec = 941.0970 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6212 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6212 Mbps 0 retrans 112.1875 MB / 1.00 sec = 941.0970 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6212 Mbps 0 retrans 112.2500 MB / 1.00 sec = 941.6222 Mbps 0 retransnuttcp-t: 1123.1250 MB in 10.00 real seconds = 115007.61 KB/sec = 942.1423 Mbpsnuttcp-t: retrans = 0nuttcp-t: 17970 I/O calls, msec/call = 0.57, calls/sec = 1796.99nuttcp-t: 0.0user 0.2sys 0:10real 2% 0i+0d 464maxrss 0+2pf 17950+1csw nuttcp-r: 1123.1250 MB in 10.01 real seconds = 114910.71 KB/sec = 941.3485 Mbpsnuttcp-r: 70091 I/O calls, msec/call = 0.15, calls/sec = 7003.17nuttcp-r: 0.0user 0.6sys 0:10real 6% 0i+0d 334maxrss 0+19pf 52135+5csw
TriFortネットワークベンチマーク測定 (PING応答 )
ping x.x.x.119PING x.x.x.119 (x.x.x.119) 56(84) bytes of data.64 bytes from x.x.x.119: icmp_seq=1 ttl=64 time=1.29 ms64 bytes from x.x.x.119: icmp_seq=2 ttl=64 time=0.046 ms64 bytes from x.x.x.119: icmp_seq=3 ttl=64 time=0.049 ms64 bytes from x.x.x.119: icmp_seq=4 ttl=64 time=0.046 ms64 bytes from x.x.x.119: icmp_seq=5 ttl=64 time=0.045 ms64 bytes from x.x.x.119: icmp_seq=6 ttl=64 time=0.041 ms64 bytes from x.x.x.119: icmp_seq=7 ttl=64 time=0.048 ms64 bytes from x.x.x.119: icmp_seq=8 ttl=64 time=0.067 ms64 bytes from x.x.x.119: icmp_seq=9 ttl=64 time=0.047 ms64 bytes from x.x.x.119: icmp_seq=10 ttl=64 time=0.043 ms
AWSネットワークベンチマーク測定(AWS EC2 172.31.32.40 > 172.31.36.123)
AWS EC2 172.31.32.40 > 172.31.36.123# nuttcp -v -i1 172.31.36.123nuttcp-t: v6.1.2: socketnuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> 172.31.36.123nuttcp-t: time limit = 10.00 secondsnuttcp-t: connect to 172.31.36.123 with mss=1448, RTT=0.376 msnuttcp-t: send window size = 19800, receive window size = 87380nuttcp-t: available send window = 14850, available receive window = 65535nuttcp-r: v6.1.2: socketnuttcp-r: buflen=65536, nstream=1, port=5001 tcpnuttcp-r: interval reporting every 1.00 secondnuttcp-r: accept from 172.31.32.40nuttcp-r: send window size = 19800, receive window size = 87380nuttcp-r: available send window = 14850, available receive window = 65535 26.6250 MB / 1.00 sec = 223.3427 Mbps 0 retrans 29.2500 MB / 1.00 sec = 245.3670 Mbps 0 retrans 28.0000 MB / 1.00 sec = 234.8808 Mbps 0 retrans 29.1875 MB / 1.00 sec = 244.8430 Mbps 0 retrans 19.6875 MB / 1.00 sec = 165.1507 Mbps 0 retrans 7.8125 MB / 1.00 sec = 65.5343 Mbps 0 retrans 7.8125 MB / 1.00 sec = 65.5376 Mbps 0 retrans 7.8125 MB / 1.00 sec = 65.5360 Mbps 0 retrans 7.8125 MB / 1.00 sec = 65.5361 Mbps 0 retrans 7.8125 MB / 1.00 sec = 65.5360 Mbps 0 retransnuttcp-t: 172.2500 MB in 10.00 real seconds = 17638.31 KB/sec = 144.4931 Mbpsnuttcp-t: retrans = 0nuttcp-t: 2756 I/O calls, msec/call = 3.72, calls/sec = 275.60nuttcp-t: 0.0user 0.0sys 0:10real 1% 0i+0d 474maxrss 0+2pf 2748+1csw nuttcp-r: 172.2500 MB in 10.05 real seconds = 17544.41 KB/sec = 143.7238 Mbpsnuttcp-r: 21819 I/O calls, msec/call = 0.47, calls/sec = 2170.27nuttcp-r: 0.0user 0.9sys 0:10real 9% 0i+0d 334maxrss 0+19pf 19189+4csw
AWSネットワークベンチマーク測定(Ping応答 172.31.32.40 > 172.31.36.123)
# ping 172.31.36.123PING 172.31.36.123 (172.31.36.123) 56(84) bytes of data.64 bytes from 172.31.36.123: icmp_seq=1 ttl=64 time=0.428 ms64 bytes from 172.31.36.123: icmp_seq=2 ttl=64 time=0.554 ms64 bytes from 172.31.36.123: icmp_seq=3 ttl=64 time=0.423 ms64 bytes from 172.31.36.123: icmp_seq=4 ttl=64 time=0.497 ms64 bytes from 172.31.36.123: icmp_seq=5 ttl=64 time=0.479 ms64 bytes from 172.31.36.123: icmp_seq=6 ttl=64 time=0.498 ms64 bytes from 172.31.36.123: icmp_seq=7 ttl=64 time=0.589 ms64 bytes from 172.31.36.123: icmp_seq=8 ttl=64 time=0.765 ms64 bytes from 172.31.36.123: icmp_seq=9 ttl=64 time=0.578 ms64 bytes from 172.31.36.123: icmp_seq=10 ttl=64 time=2.44 ms
AWSネットワークベンチマーク測定
・OFFICE > TriFort
# nuttcp -v -i1 x.x.x.70nuttcp-t: v6.1.2: socketnuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> x.x.x.70nuttcp-t: time limit = 10.00 secondsnuttcp-t: connect to x.x.x.xwith mss=1400, RTT=12.932 msnuttcp-t: send window size = 23240, receive window size = 87380nuttcp-t: available send window = 17430, available receive window = 65535nuttcp-r: v6.1.2: socketnuttcp-r: buflen=65536, nstream=1, port=5001 tcpnuttcp-r: interval reporting every 1.00 secondnuttcp-r: accept from x.x.x.135nuttcp-r: send window size = 524288, receive window size = 524288nuttcp-r: available send window = 393216, available receive window = 393216 27.0625 MB / 1.00 sec = 227.0147 Mbps 0 retrans 39.6875 MB / 1.00 sec = 332.9235 Mbps 0 retrans 39.6250 MB / 1.00 sec = 332.3999 Mbps 0 retrans 39.8125 MB / 1.00 sec = 333.9571 Mbps 0 retrans 39.8125 MB / 1.00 sec = 333.9845 Mbps 0 retrans 40.1250 MB / 1.00 sec = 336.5922 Mbps 0 retrans 40.2500 MB / 1.00 sec = 337.6246 Mbps 0 retrans 39.7500 MB / 1.00 sec = 333.4655 Mbps 0 retrans 39.9375 MB / 1.00 sec = 335.0197 Mbps 0 retrans 39.9375 MB / 1.00 sec = 335.0190 Mbps 0 retransnuttcp-t: 386.0625 MB in 10.00 real seconds = 39532.70 KB/sec = 323.8519 Mbpsnuttcp-t: retrans = 0nuttcp-t: 6177 I/O calls, msec/call = 1.66, calls/sec = 617.70nuttcp-t: 0.0user 0.6sys 0:10real 6% 0i+0d 472maxrss 0+2pf 6283+6csw
nuttcp-r: 386.0625 MB in 10.01 real seconds = 39478.09 KB/sec = 323.4045 Mbpsnuttcp-r: 28355 I/O calls, msec/call = 0.36, calls/sec = 2831.58nuttcp-r: 0.0user 0.6sys 0:10real 5% 0i+0d 326maxrss 0+20pf 23166+34csw
AWSネットワークベンチマーク測定
・ Ping応答 OFFICE > AWS東京
# ping x.x.x.70PING x.x.x.x(x.x.x.70) 56(84) bytes of data.64 bytes from x.x.x.70: icmp_seq=1 ttl=55 time=6.44 ms64 bytes from x.x.x.70: icmp_seq=2 ttl=55 time=4.69 ms64 bytes from x.x.x.70: icmp_seq=3 ttl=55 time=4.60 ms64 bytes from x.x.x.70: icmp_seq=4 ttl=55 time=4.53 ms64 bytes from x.x.x.70: icmp_seq=5 ttl=55 time=4.22 ms64 bytes from x.x.x.70: icmp_seq=6 ttl=55 time=7.94 ms64 bytes from x.x.x.70: icmp_seq=7 ttl=55 time=4.56 ms64 bytes from x.x.x.70: icmp_seq=8 ttl=55 time=7.82 ms64 bytes from x.x.x.70: icmp_seq=9 ttl=55 time=4.13 ms64 bytes from x.x.x.70: icmp_seq=10 ttl=55 time=4.71 ms
AWSネットワークベンチマーク測定
・OFFICE > AWS EC2 東京
# nuttcp -v -i1 ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.comnuttcp-t: v6.1.2: socketnuttcp-t: buflen=65536, nstream=1, port=5001 tcp -> ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.comnuttcp-t: time limit = 10.00 secondsnuttcp-t: connect to 54.92.35.65 with mss=1400, RTT=6.855 msnuttcp-t: send window size = 23240, receive window size = 87380nuttcp-t: available send window = 17430, available receive window = 65535nuttcp-r: v6.1.2: socketnuttcp-r: buflen=65536, nstream=1, port=5001 tcpnuttcp-r: interval reporting every 1.00 secondnuttcp-r: accept from 118.238.250.135nuttcp-r: send window size = 19320, receive window size = 87380nuttcp-r: available send window = 14490, available receive window = 65535 12.3125 MB / 1.00 sec = 103.2825 Mbps 0 retrans 16.6875 MB / 1.00 sec = 139.9787 Mbps 0 retrans 16.4375 MB / 1.00 sec = 137.8931 Mbps 0 retrans 14.1875 MB / 1.00 sec = 119.0134 Mbps 0 retrans 16.4375 MB / 1.00 sec = 137.8880 Mbps 0 retrans 17.0000 MB / 1.00 sec = 142.6076 Mbps 0 retrans 15.5000 MB / 1.00 sec = 130.0206 Mbps 0 retrans 16.8750 MB / 1.00 sec = 141.5607 Mbps 0 retrans 16.3125 MB / 1.00 sec = 136.8390 Mbps 0 retrans 14.6875 MB / 1.00 sec = 123.2080 Mbps 0 retransnuttcp-t: 156.5000 MB in 10.00 real seconds = 16025.55 KB/sec = 131.2813 Mbpsnuttcp-t: retrans = 0nuttcp-t: 2504 I/O calls, msec/call = 4.09, calls/sec = 250.40nuttcp-t: 0.0user 0.1sys 0:10real 1% 0i+0d 544maxrss 0+1pf 2606+3csw
nuttcp-r: 156.5000 MB in 10.01 real seconds = 16006.72 KB/sec = 131.1270 Mbpsnuttcp-r: 18553 I/O calls, msec/call = 0.55, calls/sec = 1853.11nuttcp-r: 0.0user 0.8sys 0:10real 8% 0i+0d 334maxrss 0+20pf 16134+7csw
AWSネットワークベンチマーク測定
・ Ping応答 OFFICE > AWS EC2 東京
# ping ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.comPING ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65) 56(84) bytes of data.64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=1 ttl=55 time=6.72 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=2 ttl=55 time=12.2 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=3 ttl=55 time=7.18 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=4 ttl=55 time=10.4 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=5 ttl=55 time=12.9 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=6 ttl=55 time=11.3 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=7 ttl=55 time=7.69 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=8 ttl=55 time=10.1 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=9 ttl=55 time=6.05 ms64 bytes from ec2-54-92-35-65.ap-northeast-1.compute.amazonaws.com (54.92.35.65): icmp_seq=10 ttl=55 time=8.00 ms