GP2 EBSの16TB化において知りたいたった1つのこと：ベースラインパフォーマンス比率 | cloudpack技術情報サイト
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 以下のAWSの発表のとおり、SSDベースのAmazon EBSの最大容量およびIOPSが近々強化される予定だそうです。 Amazon Web Services ブログ: 【AWS発表】さらに大容量で高速なElastic Block Store(EBS)ボリューム 変更点 従来からの変更点は以下のとおり GP2 (General Purpose SSD) GP2 (General Purpose SSD) 最大IOPS：3,000 IOPS→10,000 IOPS スループット：非公開→160MB/s PIOPS (Provisioned IOPS SSD) 最大容量：1TB→16TB 最大IOPS：4,000 IOPS→20,000 IOPS スループット：非公開→320MB/s また、この明確なスループッ
Route53 を使って Sensu の RabbitMQ を HA 構成にしてみた | iret.media
cloudpack の 自称 Sensu芸人 の かっぱこと 川原 洋平（@inokara）です。 はじめに Sensu をプロダクション環境で運用しようとすると、その中核となる RabbitMQ はどう見ても SPOF になるんでは？という疑問から HA Proxy や Route 53 を使って HA 構成がとれないか検証してみた。 下記のように Sensu クライアント及び Sensu サーバーが Route 53 に定義されたドメイン名に対してアクセスするような構成を構築して検証する。 尚、今回は ElastiCache for Redis は用いずに Sensu サーバー上に構築した Redis サーバーを利用した。 Route53 による Health Check の設定 参考 Route53のDNSフェイルオーバー機能を使ってみた 設定の条件 RabbitMQ ノードのグロー
CloudFrontでhttpリクエストをhttpsにリダイレクトできるようになった | iret.media
アクセスしてみる こんな感じでhttpアクセスしてみると、 ↓↓↓ httpsにリダイレクトされてました。 今回はS3ホスティングで試しましたが、EC2でWebサイトをホスティングするときも同様です。うちでよく組む構成だと、EC2でWebサイトをホスティングする場合、CloudFrontでSSLをターミナーションして、EC2ではhttpのみで扱うことも多く、EC2側のApacheでhttpsにリダイレクトするような構成ができませんでしたが、この機能を有効にすればhttpでリクエストされても自動的にhttpsにリダイレクトされる構成ができるという点で有効かなと思いました。
RI戦略にいまや無視できないCPUのロードマップと新しいEC2インスタンスファミリーの関係について | iret.media
cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。 最近ローンチした最新世代のEC2インスタンスファミリーでは、使用しているCPUの型番が公開されています。 インスタンスタイプ – Amazon EC2 (クラウド上の仮想サーバー Amazon Elastic Compute Cloud) | アマゾン ウェブ サービス（AWS 日本語） 旧世代のM1やC1といったインスタンスファミリーは「インスタンスガチャ」をするとCPUに当たり(新しいアーキテクチャの)/ハズレ(古いアーキテクチャの)があるなんてことを言われてました。最近はどうか分かりませんけど。 油断もすきもならないECU IntelのCPUの一般発売時期と、CPUが公開されてるインスタンスファミリーのローンチ時期 Intel Xeon x5570 (2009Q1) CG1 (2010Q4)：NVID
cloudpackブログ -NginxのアクセスログにELBの"400 Bad Request"エラー(まとめ)
ELBの下のNginxで、下記のアクセスログが頻繁にみられました。 ("x.x.x.x"はELBのIPアドレスです) x.x.x.x - [16/Nov/2012:00:00:17 +0900] 0.000 "-" 400 0 "-" "-" 0 0 x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0 x.x.x.x - [16/Nov/2012:00:00:18 +0900] 0.000 "-" 400 0 "-" "-" 0 0 上記の減少はElastic Load Balancer にぶら下がってる時の access logで非常に詳しく説明されていました。 つまり、ELBがsecond health checkと言われるコネクションを開いて閉じるだけの チェックを行い、それがNginxのアクセスログで
cloudpackブログ - HAProxy(1.4)でMySQLの自動フェイルオーバーにあわせて接続先を変更
VPC上のEC2(CentOS 6.0)でDRBD(8.3)とHeartbeat(3.0)とMySQL(5.5)の記事で自動フェイルオーバーするMySQLができたので、次は、それに合わせて接続先を変更する仕組みを考えます。 EC2はVPCの場合でも、仮想IPアドレスを利用することができないので、まず、hostsファイルを変更したり、内部DNSをたて、DNSレコードを変更したりして、自動フェイルオーバーに合わせた接続変更(接続ホスト名のIPアドレスを変更)を行う方法を考えると思います。 ただ、上記の方法ではミドルウェアのインストールや設定のみでは完結せず、多少の仕組みの作り込みが必要になってしまうはずです。 今回は、MySQLに接続するサーバには必ずHAProxyをインストールし、アプリケーションはlocalhostのMySQL(HAProxy)に接続し、フェイルオーバーに伴う接続先変更はH
cloudpackブログ - VPCでRDSをMulti-AZで作成しようとしたところap-northeast-1cが足りないと言われました
VPC上にてRDSをMulti-AZで作成しようとしたところ、 下記のようなエラーが発生し、作成ができなくなっていました。 今まで作成できたはずなのですが・・・ No subnet is in availability zone ‘ap-northeast-1c’, the subnets in a subnet group should cover all availability zones. 要約しますと “ap-northeast-1c”のサブネットがありません。DBサブネットグループに登録する サブネットは、すべてのAZをカバーするようにしなければなりません。 ということのようです。 DBサブネットグループを確認してみたところ下記のように “ap-northeast-1a”と”ap-northeast-1b”、それぞれで作成したサブネットのみが登録されていました。 そこで “ap
cloudpackブログ - SimpleDBにSyslogっぽいログを出力(保存)
Auto Scalingで起動しているEC2インスタンスは、自動的にターミネートするので、ログはEC2インスタンスではなく、他の場所に出力する必要があります。 出力場所はSimpleDBに出力し、ログのフォーマットをSyslogのようにして、Syslogラッパーにもつなげたいと考えています。 尚、Syslogのフォーマットは、 timestamp, facility, priority, tag, message 上記のように、さらにインスタンスIDも出力するようにしています。 だいぶ肥大化してしまいましたが、いつもの共通部分です。 EC2起動時に設定できるUser DataをPHPで利用するで紹介したやり方を応用してインスタンスIDを取得し、定義したログ出力用の関数(logger)を、SmpleDBに出力するようにしています。 ▼ common.php define("AWS_KEY"
cloudpackブログ - RDSのスナップショットの上限は20がデフォルトのようです
RDSのスナップショットを取得するPHPスクリプトが、下記のようなエラーを出力し、 スナップショットを取得することができないという現象が起こりました。 cannot create more than 20 user snapshots RDSのスナップショットを取得できる上限は、RDSインスタンスと同じ20がデフォルトのようです。 下記でも同じようなことを質問していました。 「cannot create more than 20 user snapshots」 on RDS? RDSのスナップショットを取得できる上限を上げるためには、下記のフォームから申請する必要があります。 下記のフォームは、RDSインスタンスの上限値を上げるためのフォームですが、 自由入力欄で別途、スナップショット数の上限値の変更を依頼すると、 インスタンス数とは別の上限値をスナップショットの上限値として設定できるよう
cloudpackブログ - s3fs-suz
s3fsからs3fs-cへとgithubでforkしてローカルにcloneしてadd&commit&pushの続きになります。 s3fs-suzとして、差し当たり、s3fs-1.59からの下記の変更をs3fs-cにマージしました。 (完璧ではないかもしれませんが。) r357 , r358 , r359 , r360 , r361 , r362 メモリリーク対応系までの変更をマージし、5G以上のファイル対応はマージしていない形となります。 ちなみに、s3fs-cの制限は下記となります。 UID/GIDはサポートせず、オーナーやグループはすべてroot ファイルやディレクトリのパーミッションはrwxrwxrwxにハードコード @memorycraft、使ってみて下さい。 こちらの記事はなかの人（suz-lab）監修のもと掲載しています。 元記事は、こちら
cloudpackブログ - RDSのフェイルオーバーに関する注意点
RDSはMulti-AZで利用していると、時々フェイルオーバーしてしまいます。 フェールオーバーした時の確認は、下記のようにAWS Management Consoleで確認することが可能です。 当然、API(DescribeEvents)でも確認することができ、APIのドキュメントを確認すると、イベントログが保存される期間は、14日間のようです。(CloudWatchと同様) とても便利な機能なのですが、一つ注意点があります。 RDSがフェイルオーバーするということは、RDSが別ゾーンに切り替わってしまうということになります。 パフォーマンス面のことを考え、バッチ処理を行うようなEC2インスタンスとRDSをあえて同じゾーンにしていた場合は、別ゾーンになってしまうと、パフォーマンス的に良くない状態になります。 例として、大量の連続したトランザクションを処理する場合には、通信のレイテンシーが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
cloudpackブログ - JAWS-UG山口第2回勉強会『RDS（MySQL）の利用と注意点』を公開しました
cloudpackブログ - ELBのヘルスチェックで指定できる最大値と最小値