それほどCPU負荷も高くないはずなのになんとなく「もっさり」してる…という事案に直面している方のお役に立てるかもしれません。 困っていたこと 状況の把握 対象となるサーバ群はApache/PHPでサービスを提供しています。 AWS/ParaVirtual/c3.2xlargeという構成ですので、8coreが利用できる状態です。 稼働中の問題点は以下のようなものです。 特定のコアに負荷が偏っている CPU負荷としてはそれほど高くないはずなのに、ネットワーク転送などが時々詰まる top - 19:29:57 up 9:08, 1 user, load average: 0.92, 0.70, 0.69 Tasks: 427 total, 3 running, 424 sleeping, 0 stopped, 0 zombie Cpu0 : 54.6%us, 5.7%sy, 0.0%ni, 25
Amazon EC2 インスタンスでの拡張ネットワーキング - Amazon Elastic Compute Cloud
拡張ネットワーキングでは、シングルルート I/O 仮想化 (SR-IOV) を使用して、サポートされるインスタンスタイプにおける高性能ネットワーキング機能が提供されます。SR-IOV は、従来の仮想化ネットワークインターフェイスと比較し、I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。拡張ネットワーキングは、より高い帯域幅、1 秒あたりのパケット (PPS) のより高いパフォーマンス、常により低いインスタンス間レイテンシーを実現します。拡張ネットワーキングは追加料金なしで使用できます。 各インスタンスタイプでサポートされているネットワーク速度については、Amazon EC2インスタンスタイプを参照してください。 次のいずれかのメカニズムを使用して、拡張ネットワークを有効にすることができます。 Elastic Network Adapter (ENA) Elast
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最低限セキュアな構成とは 「最低限セキュアな構成」を次のように定義する。 Webサーバーやデータベースサーバーが直接、インターネットに公開されていない。 公開・非公開に関わらず、特定のポートのみインバウンドを受け付けている。 非公開のサブネットは特定のサブネットからのみインバウンドを受け付けている。 踏み台サーバーは必要な時のみ存在している。 この定義を満たす構成は次のようになる。 構築手順 ざっくりと以下の手順を踏む。 VPCの構築 パブリックSubnetの構築 Subnetの構築 Internet Gatewayの構築 Route
ども、大瀧です。 最近、お客さまからの問い合わせからElastic Load Balancing(ELB)の負荷分散について調べ社内資料としてまとめる機会がありました。せっかくなので、ブログ記事として公開してみます。内容は随時アップデートしますので、ツッコミ・ご指摘があればぜひお願いします！ 負荷分散の仕組み ELBは、クライアントのリクエストを受け付けEC2インスタンスにトラフィックを転送するために、2種類の負荷分散を組み合わせて動作します。 スケーラビリティと冗長性のために、ELBはロードバランサの機能を提供するノードを複数動作させるはたらきがあり、クライアントから複数のノードへアクセスを分散させるためにDNSラウンドロビン、ノードからEC2インスタンスへのトラフィック転送を分散させるためにLeast Connsという手法を用いています。 DNSラウンドロビン DNSラウンドロビンはそ
2014年09月05日15:25 カテゴリインフラAWS Amazon VPC と仮想プライベートゲートウェイを使わずに繋いでみたかったのでやってみた こんにちは、adingo で Fluct という広告配信まわりのインフラやってる あわいいしま (@katz_arc) です。 月間200億超のインプレッションを捌くSSP である Fluct を支えるべく、日夜頑張っております。 今回はタイトルの通り、Amazon VPC で使える仮想プライベートゲートウェイを使わずにオンプレのデータセンター (以下 IDC) と VPC の間を VPN 接続したお話です。 前提 過去には仮想プライベートゲートウェイを利用して VPN 接続を構築したこともあります。 それが何故、その VPN 接続を使わずに自前で構築しようと考えたか、そこには2つほど理由がありました。 1. ゲートウェイを作成するたびに
はじめに Amazon LinuxをはじめとするEC2インスタンスはグラフィカルログインが提供されていませんのでWireSharkによるリアルタイムキャプチャーができません。そのため、EC2の入出力パケットをキャプチャーをするにはtcpdumpでキャプチャーして、そのファイルをローカルのPCにダウンロードしてWireSharkで確認します。この方法は、手間が多いだけでなく、ネットワークに流れるパケット情報をリアルタイムで調査できるWireSharkの長所が失われてしまします。 キャプチャー対象となるEC2インスタンスの設定変更と添付したシェルの設定項目を書き換えのみで、リモートキャプチャーできるランチャーを作成しましたのでご紹介します。 ５分で手早く利用したい方は、下記のシェルと設定ファイルをコピーして、図を参考に設定を置き換えることで動作できるでしょう。 WireSharkのリモートキャ
![[EC2]５分でできる！？ WireSharkのリモートキャプチャー | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/fd4e7bee249c97d151c0e5350794553cde01b61e/height=288;version=1;width=512/https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2014%2F08%2Fwireshark_icon.jpg){kind=icon}
ども、大瀧です。 LinuxのEC2インスタンスでちょっと変わったネットワーク設定をしようとすると、思う通りに動かなかったり設定が見えなかったりと、オンプレミスとは雰囲気の異なる振る舞いをすることがあります(本質的にはオンプレミスとなんら変わらないのですが)。自身で経験したケースをメモ書きとして残しておきます。 想定するLinux OS : Amazon Linux, CentOS 6.x, RHEL 6.xなどRed Hat系ディストリビューション /etc/resolv.confを変更したのになぜか元に戻ってしまう DHCPクライアントによるものです。DHCPクライアントは定期的にIPアドレス更新の問い合わせをDHCPサーバーに行いますが、そのときに付随するDNSの情報を元にデフォルトで/etc/resolv.confファイルを上書きします。これを無効にするためにNICの設定ファイル/
2015/12/18追記 マネージドNATが出たので、わざわざNATを建てずにこちらをまず検討すると良いと思う。 Amazon Web Services ブログ: 【新機能】マネージドNATゲートウェイが利用可能に ーーー t2.microでNATインスタンスを建てようとするも、NAT用AMIは PVしかない(2014年7月11日時点)という理由で諦めてる人向けのメモ。 (NATインスタンスの建て方自体は、このページ末尾のSlideshareを参考に) 基本的にやることはPVもHVMも変わらず、 ip_forward有効にしているLinuxを起動 EC2の設定で src/dst checkをdisabledにしておく routing tableを適切に設定しておく これさえキチンとしていれば、たいていのLinuxで( Vyatta等を含む)動作するので、HVMかPVかはそもそも関係ない。(
EC2ではマルチキャストが使えないから○○が動かないってよく聞きます。確かにVPCであってもEC2ではL2ブロードキャストはサポートされていないので、ENIにブロードキャスト/マルチキャストパケットを投げても誰にも届きません。でも当たり前ですが、ユニキャストはできますよね？であればアプリケーションがマルチキャストのつもりで投げたパケットを捕まえて、L3アドレスはそのままにL2で複数のユニキャストフレームとして送ってしまえばいいのでは？そんな事を試して実際動く事を確認したところをデモを含めてお届けします。
AWSソリューションアーキテクトの安川 (@thekentiest)です。 前の荒木 (@ar1)の投稿で、トンネル技術を使えばいろんなEC2-ClassicやEC2-VPCでサポートしていないプロトコルでも利用可能であるという話がありました。その投稿でも触れられていたとおり、トンネリングを使えばIP Multicast/BroadcastもEC2インスタンス間でやりとりする（しているかのように上位レイヤのアプリケーションに思わせる）ことができるので、トンネリングを使ってIP Multicast/Broadcastを前提としたアプリケーションやミドルウェアを動かす例も多く見られます。 トンネリングは汎用的で、様々なプロトコルを動作させる目的で使える点は優れています。しかし、通信のオーバーヘッドが伴うのはもとより、特定のノード間でトンネリングをする設定をしないといけないので、その部分が煩雑で
フェイルオーバーを実現する手法のひとつにVIP(Virtual IP、浮動IPアドレス)というものがあります。 Amazon VPCにてVIPができないか、ちょっと考えてみたのでそのメモです。 環境としては、10.0.0.0/16のVPCの中に、 10.0.0.0/17のpublic subnet (AZはa) 10.0.128.0/17のpublic subnet (AZはb) というそれぞれ別のAvailability Zoneに属する2つのsubnetを作り、これらsubnetをまたいでVIP的なことができないか、という考察です。 思いついた方法としては以下の3つです。 ENIを移動する - NICを移動する secondary private addressを移動する - IP Aliasする Routerの力を借りる ほかにもいい方法があったら教えてください＞＜ ENIを移動する
前回、ブラックリスト型ファイヤーウォールとしてネットワークACL（NetworkACL）を紹介しました。セキュリティグループとの役割の違いが解り難いところがあるので、改めて整理してみたいと思います。 ネットワークACL（NetworkACL）とセキュリティグループ（SecurityGroup）の違い まずセキュリティグループとネットワーク ACLの違いは何でしょうか？これは、公式のドキュメントに表形式でまとめられていて非常に解りやすいので、是非一度見て頂ければと思います。表を転載すると以下の通りです。 セキュリティグループ ネットワーク ACL インスタンスレベルで動作します（第 1 保護レイヤー） サブネットレベルで動作します（第 2 保護レイヤー） ルールの許可のみがサポートされます ルールの許可と拒否がサポートされます ステートフル: ルールに関係なく、返されたトラフィックが自動的に
昨日から、色々調べ始めています。今日はAWSの上位ネットワークまわり。特に東京リージョン(Asia Pacific (Tokyo) Region)。 現時点の情報のスナップショットとしてログがわりに残しておきます。 ASN (AS番号) まず、以下のサイトで調べてみると、、、 http://bgp.he.net/search?search[search]=Amazon&commit=Search この通り、Amazonが取得しているASNは10個ほど見受けられますが、中身を見ていくと、このうちAS16509にほぼ集約されていることがわかります。 AS16509に接続されているBGPのPeerの数は現時点で、v4が158、v6が10となっています。(公開情報のみ) Peerの内訳は以下のリンク先から確認できます。 http://bgp.he.net/AS16509#_peers ざっくり確認
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
