サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
猫
xoxo-infra.hatenablog.com
Multi AZ を使う時に気になるのが、AZ間のレイテンシ。 気にならないレベルだと皆さん言いますが、地理的に数十km離れたDC間 の通信なので、どうしてもレイテンシは発生します。 裏で専用線を引いているのは確かでしょうけど。 そこで、簡易的では有りますが、実際どのくらいのレイテンシなんだろ と思ってテストしてみました。 テスト条件 ・ap-northeast-1a を基点にして、1b、1c へ ping 実行 ・各インスタンスは同タイプ ・1a,1b,1cは、同一VPC 1a → 1a 間 (インスタンスは異なる) $ ping -c 10 10.0.1.111 PING 10.0.1.111 (10.0.1.111) 56(84) bytes of data. 64 bytes from 10.0.1.111: icmp_seq=1 ttl=64 time=0.646 ms 64 b
Datadogとmackerelはそもそも立ち位置が違うので、比較してどうすんだって話もありますが、 今のところ、DataDogのほうが圧倒的に勝っています。まず、Integrationが豊富&楽すぎる。 ざっとした特徴 Datadog 課金対象はEC2のみ。(またはDatadogAgent) その他AWSサービス群は全て無料で13ヶ月保管。 極論言うと、DataDogAgentをインストールしたEC2を1台だけ契約して、その他のELBやRDSは取り放題。 ProとEnterpriseの違いはほぼ無いらしい。500台以上でもPro契約でOK。あくまで目安らしい。 CloudTrail等、諸々の情報がEventに流れてくるので便利。 オンプレでも使える。APM機能などもあり、高機能。 唯一のネックは、ログ監視がほぼ出来ないこと。 Datadogはメトリクス(数値)を受け取ってグラフ描画をする
今更ながら、VPC内におけるpublicIP、publicDNS、EIPの挙動をメモ。 なんでこのテーマかと言うと、 http://www.slideshare.net/AmazonWebServicesJapan/vp-cby-default20130404public の8ページ目の「動的割当されるPublic IPアドレスが利用できる唯一のSubnet」が 嘘くさいと思ったからです。 あと、いつの間にかNATインスタンスが要らなくなったなどの仕様変更されていたので 軽く検証してみました。 publicIP、DNSについて 1. 明示的に作成したサブネット内では、publicIPアドレスは付与されないので注意。(ほんと?) publicIPは付与される。ので資料は嘘くさい。 調べたところ、資料公開後に仕様変更され、publicIP、DNSは振られるになった。 ただし、DNS resol
表題の通り、IAMポリシーで特定のEC2インスタンスのみに操作権限を付ける ことが可能になったみたいです。(2013/07時点) http://aws.typepad.com/aws_japan/2013/07/resource-permissions-for-ec2-and-rds-resources.html 以下のIAMポリシーは、全EC2インスタンスの参照権限 + インスタンスID1、2 への再起動、起動、停止の権限を付与した例です。 ActionとResourceが重要です! { "Version": "2012-10-17", "Statement": [ { "Sid": "EC2DESC", "Action": ["ec2:describe*"], "Resource": ["*"], "Effect": "Allow" }, { "Sid": "EC2BOOT", "Ac
メモ。 redisのほうが高機能ですね。 ■全般 EC2上にmemcachedを構築するより、セットアップが楽、高可用性、 CloudWacth使用可なので便利。 RDSと同様、OSにログインは出来ない。 最近M3のインスタンスタイプが提供された。現在はmemcachedしか対応していない。 memcachedとredisだと、同じインスタンスタイプでも使えるメモリ量が異なる。 (redisのうほうが少ない) コネクション数やキャッシュが溢れたなどはCloudWactchで見れる。(+SNSも) VPC対応済み。VPC環境だとPublicIPは付与されない。 memcachedは認証の仕組みがない。(redisはある) EC2-ClassicはCacheSG、VPCは通常通りVPC SGとなる。 パッチ適用時は再起動を伴うこともある。 ElastiCacheが停止するとDBへの負荷が上がる
RDSのインスタンスタイプをsmallからmediumに変更した際に、 フェイルオーバーが走って、RDSがセカンダリAZに行ってしまった 件についてメモります。 再起動が発生する認識はありましたが、フェイルオーバーするという 認識は無く、なんでやねーんと調べてたら、以下にガッツリ書いてあ りました。。。 ・フェイルオーバー発生条件 http://aws.amazon.com/jp/rds/faqs/#43 以下が実行した際のログです。(AZは1a,1cのMulitiAZ構成) 1. ManagementConsole からインスタンスタイプ変更 2. 同時に別サーバからshow variablesをループさせて、 innodb_buffer_pool_sizeが変わるか確認。 Fri Apr 5 15:42:05 JST 2013 +-------------------------+--
大量のサーバを管理していて、共通設定のファイルを配布したり、ディレクトリの 権限変更したり、ちょっとした一斉作業に便利なコマンドpsshについてメモ。 だいぶ、今更な話ですいませんw 同時に一斉実行ですので、sshをforなどでループするより遥かに早いです。 あと、capistranoのレシピ書くほどではない作業にはもってこいです。 前提 ・pythonがインストールされていること ・ノーパスワードでサーバ間のsshログインが可能なユーザが居ること http://kenknown.blog42.fc2.com/blog-entry-92.html 導入 wget https://parallel-ssh.googlecode.com/files/pssh-2.2.2.tar.gz tar xfz pssh-2.2.2.tar.gz cd pssh-2.2.2 python ez_setup
昨年の5月頃からwebサーバのロードアベレージ閾値超えアラートが大量に 飛んでくるようになりました。 その数値が尋常ではない。。 (ロードアベレージ 1分間統計で、300~800) 月1ペースが11月頃には2日に1回のペースになっていき、ひどい時は1日で 数十件なんて日もありました。 何事かと思い、Apacheのアクセスログを解析したところ、UAが facebookexternalhit/1.1からの秒間大量アクセス(むしろアタック)が 原因であることを突き止めました。 これは、5月からわかっていたことだったのですが対策ができず、未だに解決 していません。(詳細は後述) 以下、アクセスログ例です。 ・1分間にfacebookから何アクセス来ているか (grepはざっくり) grep facebook access.log|grep "Day/Month/Year:15:44:"|wc -l
AWS関連資料を見ていると、VPC内部でのプライベートサブネット、パブリック サブネットが区分けされている構成図をよく見かける。 ・こんな感じの構成図のことを言ってます。 http://3.bp.blogspot.com/-SZ0M4g2YuVE/T9sk5ZgkYgI/AAAAAAAAF8g/ZEObU3GxEGY/s1600/scalable_app_int_lb.jpg ・そもそも、VPCとは な方は以下をご参照ください。 http://www.slideshare.net/kentamagawa/vpc-aws7 インフラを知らないアプリエンジニアなら兎も角、セキュリティ高めるために パブリック、プライベートのサブネットを分けるよね~ オンプレっ子な私はどうしても分けないと気持ち悪い&DMZはセキュリティ要件 として必須なので実装! さーてちゃちゃっとやるかと、AWS Manege
諸事情により、さくらVPSを数百台契約しているのですが、ある日突然、 某クラウドで動かしている特定のサーバ(サーバ#1)から、さくらVPS全台 へのSSH(22番ポート) に接続できなくなる事象が発生。 またいつもの " 勝手なメンテナンス/障害 " かと思い、半日ほど放置していま したが事象変わらず・・・。 pingはOK、http(80)はOK、SSH(22)のみ不可という事象で、コンソールで確認、 tracertやらtcpdumpを打つも、通信がどこで遮断されているかは不明。 某クラウドで動かしているもう一台のサーバ(サーバ#2)からは、通信オールOK。 なんとなく直感で、さくら側の上位NW機器が特定の条件を満たすと勝手に 該当ポート (今回はSSH)を弾く仕組みを持っているんじゃないかと推測。 つーことで、さくらVPS側のSSHのポートをハイポート(10000とか)に変えたら ログ
表題の件ですが、さっくりできます。 ただし、Route53に登録するということは、全世界から参照できてしまう ということを忘れずに! # というものの、プライベートIPなので外部から接続は出来ないはずです。 # 内部でDNS立てるか、hostsで運用するか、Route53で運用するかは # 割り切りですね。 ドメイン準備 1. お名前.comなどで、好きなドメインを取得する。(例. aws-local.net) 2. 上記で取得したドメインのネームサーバ(NS)をAWSのNSに向ける。 ※Route53で表示されたNSを設定して下さい。(都度変わります) ns-410.awsdns-51.com ns-1078.awsdns-06.org ns-1734.awsdns-24.co.uk ns-866.awsdns-44.net Route53にドメイン&Aレコードを設定 1. AWS Ma
unicorn 起動スクリプトを作成してみました。 というか、OS標準のrubyがインストールされている状態で、別Verのrubyを ソースインストールしたら、OSリブート時にunicornが自動起動されなかったので メモ。 ちなみに、手動で起動スクリプトをキックした場合は正常に動作する状態です。 OSリブート時のエラーメッセージ /usr/lib/ruby/site_ruby/1.8/rubygems/dependency.rb:247:in `to_specs': Could not find unicorn (>= 0) amongst [aws-sdk-1.8.1.2, json-1.4.6, nokogiri-1.5.6, uuidtools-2.1.1] (Gem::LoadError) from /usr/lib/ruby/site_ruby/1.8/rubygems/dep
セキュリティ要件等で、各サーバのログを長期保存しなければいけない場合、 サーバ上(EBS)に全ログを保存するとエライことになるので、S3に退避する 方法をメモ。 Linux標準の logrotate + s3cmd を駆使して実現できます。 # 巷で話題のfluentdやfluent-agent-liteも検討しましたが、やりたい事は # 単純で、EC2外に大量の過去ログを保存したいだけなので、logrotateでさく # っと実装。 /etc/logrotate.d/syslog の場合 /var/log/messages /var/log/xxxx { copytruncate sharedscripts postrotate /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true ends
超小ネタ。 今まではサーバからメールが送信されるかの確認を行う場合、以下の コマンドで実施していたのですが、AmazonLinuxはmailコマンドが mailx なので、ちょっとハマりました。 てか、mailxとか初めて知った・・・orz 今まで ・送信 (送信先アドレス、送信元アドレスの順) echo test | mail -s "TEST" "hoge@test.com" -- -f "fuga@domain.com" AmazonLinux (というか、mailxの場合) ・パッケージ確認 $ which mail /bin/mail $ rpm -qf /bin/mail mailx-12.4-6.6.amzn1.x86_64 $ ・送信 (送信元アドレス、送信先アドレスの順) $ echo test | mail -s "test" -r "fuga@domain.com"
ELBには、サーバ負荷やELB負荷をトリガーとして、ELB配下にぶら下がるEC2 インスタンスを増減できます。 これを AutoScaling と呼びます。 通常はCloudWatch+SNSで、AutoScalingさせるのがカッコいいやり方ですが、 本稿ではAutoScalingの基本動作を理解する為、手動で AutoScaling をする 方法を書き綴ります。 参考 http://www.slideshare.net/kentamagawa/elb-auto-scaling-cloudwatch-aws5 http://understeer.hatenablog.com/entry/2012/02/29/175334 前提 ・オートスケール用AMIが作成済みであること(Apache自動起動ON状態) ・ELBが作成済みであること(検証用として準備) AutoScaling設定 (as
ここ(http://aws.amazon.com/jp/ec2/instance-types/instance-details/)に明確な数値が 書いてないので、インスタンスタイプ毎のAZ間のスループットを計測してみました。 東京リージョンの 1a から 1b、1c に対してnetperfで負荷を掛けています。 (AZはAWSアカウント毎にDC群が異なりますので結果は目安として下さい。) EIP間の通信ではない&同一VPC内のプライベートネットワーク間の通信を 計測対象としています。 計測方法 ・各AZに small、large、xlarge インスタンスを立てて、 netperf -f M -H 対象ホスト でスループットを計測。 ・試行回数は30回とし、平均値を取得。 ・負荷掛け側/掛けられる側のインスタンスタイプは同じとする。 スループット計測結果 ・単位はMbps、30回の平均値。
general_log を truncate (正確にはrename&drop)するのに困ったのでメモ。 slow_log、general_log をAPIから参照でき、自動ローテートまでされる(ただし24h 分しか保持されない)ようになりましたが、途中でこれらのログ出力を無効にすると、 ローテートも止まるようです。 ・APIからのRDSログ監視について http://xoxo-infra.hatenablog.com/entry/2013/03/12/205032 ローテートが止まる = ログテーブルは肥大したまま となってしまいます。 RDSで使用出来るユーザの権限の問題で、general_logに対して、truncateもdelete も実行できないのですが、これを解消する為にRDSには、いくつかのストアドプロシ ージャが用意されています。 ・ストアドプロシージャ一覧は以下で確認でき
Apache Bench飽きたし他に何か無いのかな~と探したら、weighttp にたどり着きました。 (SSL未対応ですが・・・) ほんとは、ApacheJmeterで小難しいシナリオ作ってWebサーバの負荷試験を 行うのがベストだと思いますけどね。 ・参考にしたサイト http://www.iij.ad.jp/company/development/tech/activities/weighttp/index.html#Message-complete http://matsu911.github.io/waf_book_ja/#_%E3%83%80%E3%82%A6%E3%83%B3%E3%83%AD%E3%83%BC%E3%83%89%E3%81%8A%E3%82%88%E3%81%B3%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3
mon-get-stats(CloudWatch API)を使って、RDSやELBのリソース情報を 取得する方法をメモ。Nagios、muninなどのプラグインに組み込みました。 ・過去記事 http://xoxo-infra.hatenablog.com/entry/2013/04/04/024554 ・CloudWatch API http://aws.amazon.com/developertools/2534 ・mon-get-stats http://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/cli-mon-get-stats.html RDSのリソース情報取得 ・CPU (Percent) mon-get-stats \ --metric-name "CPUUtilization" \ --statis
自分用にメモ。 複数台あるMySQLスレーブサーバへの参照クエリの負荷分散は LVS(keepalived+ipvsadm)、HAproxy、またはアプライアンス製品 (BIG-IP/A10/Zeus)などで、構成するのが一般的かと思います。 AWSには言わずと知れたロードバランサー「ELB」があります。 外部(インターネット)からのトラフィックだけでなく、プライ ベートサブネット(VPC)間のトラフィックも負荷分散できます。 ※通称 内部ELB。ELB作成時にinternalにチェック ELBについて分り易い資料 http://aws.typepad.com/aws_japan/2012/06/internal-elastic-load-balancers-in-the-virtual-private-cloud.html http://www.slideshare.net/Amazon
EC2または、RDSのPIOPSに指定できる値について。 PIOPSは、あくまで高速化というより、一定のIOPS値を保証する と言った意味合いになります。 ベンチマークを取ると解るのですが、使わないほうがIOPS値が 高い場合があります。 ※RDSとEC2では上限値が異なります。 ・PIOPSとはなんぞやな方は以下のP36を参照願います。 http://www.slideshare.net/AmazonWebServicesJapan/aws-16148274 ・EC2の場合 Disk容量とPIOPSの比率が、1:10 である必要があるようです。 Disk容量 100GB の場合、ディスクサイズの10倍の「1000 PIOPS」までしか 指定できません。 (例) データ容量 100GB なら、PIOPSは1000 また、上限はDisk容量に関わらず、1EBSあたり 2000 PIOPSまで
AWSには「S3」という便利なサービスが御座います。 まずは、S3の概要を書きます。 どんなものか超絶簡単に言うと、DropBoxやGoogleDriveが超進化 した感じです。 資料 (これを見れば大体わかります) http://www.slideshare.net/AmazonWebServicesJapan/20120319-aws-meisterreloadeds3-13318721 基本的にはGUI(AWS Management Console)から、バケット(入れ物)や その下にフォルダを作ったり、そこにインターネット経由でファイル をアップしたり色々と出来ます。 ちなみに、バケット名はドメイン名みたいなものなので早い者勝ちです。 更に何が便利かというとGUIなんて煩わしいぜという人向けに、 コマンドやAPIが公開されており、サーバからS3を操作出来ます。 cronに仕込んでE
このページを最初にブックマークしてみませんか?
『雑多なインフラエンジニア日記』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く