AWS: JavaのDNSキャッシュ ( TTL )について - aws memo
AWSのサービスではDNSを用いて可用性を向上する仕組みを用いている。 各種APIのエンドポイント RDSのエンドポイント ELBのエンドポイント ElastiCacheのエンドポイント CloudSearchのエンドポイント Redshiftのエンドポイント などなど。AWSが提供するエンドポイントのFQDNを、自分のアプリケーションから参照するように設定したり、一旦DNSでCNAME設定することも多い。 ただし、これらのエンドポイントFQDNで設定されているIPアドレスは、運用中に変更される可能性がある（ノード障害、フェイルオーバー等によるIPアドレス変更、スケーリングによるIPアドレス増減、等）。そのため、アプリケーション側はエンドポイントのIPアドレス変更に追随する必要がある。（追随しないと、古いIPアドレスにアクセス試行しつづけて、結果としてシステム障害になってしまう） ここで問
RDS: Provisioned IOPS (PIOPS)の性能について覚書き - aws memo
EBSでのProvisioned IOPS (以下 PIOPS) が出て、しばらくして RDSでも PIOPSに対応した。その後、RDSのIOPS上限が10,000から30,000に引き上げられた。 Amazon Web Services ブログ: 【AWS発表】Amazon RDS がスケールアップ! 3 TB、30,000 PIOPSまで拡張可能に され、これでRDSでIOPS30,000の性能が出る！とおもいきや、落とし穴（注意書き）が。 Factors That Affect Realized IOPS Rates 実際に出るIOPSは、ページサイズとネットワーク帯域に依存する。ページサイズはDBエンジン毎にきまっている。IOPSはDBインスタンスサイズやDBの負荷パターンにも影響をウケる。 DB EnginePage SizeMaximum IOPS Rate MySQL 16
EC2: GlusterFS in AWS - aws memo
GlusterFS on AWSといえば、 #ヤマン のスライドですね。(後述) こちらの記事では、実際の設定手順等が書かれてある。 GlusterFS in AWS | Celingest Blog – Feel the Cloud ---以下、拾い訳-- 事前の考慮点 アベイラビリティゾーン(AZ)を跨いだ2台のサーバで ext4なEBSボリュームを複製する、といった検証(PoC)に入る前に、GlusterFSを使うべきではない場合を列挙した。 複数同時にシーケンシャルにファイル書き込みをする場合： ログのように複数のサーバから書き込まれる、というようにGlusterFSにログを保存する場合、ロック機構( locking system) が、深刻な問題を引き起こす可能性がある。理想的な解決方法は、ローカルのログに追記書き込みし、S3にアーカイブする方法。必要であれば、S3にログを保存す
ElastiCache: AutoDiscovery をPHPで使う - aws memo
ElastiCacheに AutoDiscovery機能が付き、phpクライアントも出た。（Cache Engine 1.4.14以降で有効） ちょうど１年前に、このような記事(Amazon ElastiCache の分散方法 )を書いたが、この際は、ElastiCacheの複数ノードを扱うには、Mamcached::addServers() で全ノードのEndpointをハードコードする必要があった。（もしくは、ElastiCache APIのDescribeCacheClusters等を使ってEndpointを取得してServerListを設定する） AutoDiscoveryのメリット システムの負荷に応じてElastiCacheのノード増減を運用時に行う際、ハードコードが入り込むのは運用上避けたいがそのための仕組みを作りこむ負荷が必要だった。AutoDiscovery対応のMemc
EC2: User Dataを使ってインスタンス起動時の処理を自動化する - aws memo
インスタンス起動時に目にするUser Dataって何？って感じなので取り敢えず。 #!/bin/bash -ex yum -y install httpd php php-pear php-xml yum -y install git /etc/init.d/httpd start pear channel-discover pear.amazonwebservices.com pear install aws/sdk といったように、「#!」(Hash-bang)から始まる文字列を User-data記述すると、Amazon LinuxのCloud-initによって、起動時に実行される。スクリプトを記述したファイルを指定することも可能。 実行された様子は、起動したインスタンスの /var/log/cloud-init.log に記述される。 User-dataは、16KB上限であれば、ど
訳:DynamoDB:SSD Hot S3 Cold パターン - aws memo
DynamoDBのベストプラクティス的なパターン High Scalability - High Scalability - DynamoDB Talk Notes and the SSD Hot S3 Cold Pattern ＝＝＝＝ Amazon DynamoDB for Developersトークに参加する前の、DynamoDBに対する印象は、シンプル・速い・スケーラブル・地理的冗長性・使うには高い・運用不要、という、Amazonのいつもの品質のサービスだった。 トークの後、印象はより微妙(nuanced)になった。品質の印象はそのまま。フォーラムを見れば、すべてのプロダクトに典型的な問題があることがわかるが、それは驚きではない。SimpleDBの発展版( SimpleDB++)として、DYnamoDBはセカンドシステム症候群を避けて、もっとエレガントな設計を作ったように見える。
訳：Amazon DynamoDB : いつDynamoDBを使うべきか？ - aws memo
http://aws.amazon.com/jp/dynamodb/#whentousedynamodb いつDynamoDBを使うべきか？いつRDBを使うべきか？ 最近のwebベースアプリケーションは大量のデータを生成・消費する。例えば、オンラインゲームをスタートするときは数千ユーザで軽いデータベース負荷（10write/sec, 50reads/sec)程度である。しかし、ゲームが成功すると、すぐに数百万人のユーザと１万～数万/secのread/writeが発生する。また、数TB/day のデータが生成される。アプリケーションをAmazon DynamoDBベースで開発することで、小さく開始することができ、ダウンタイムやコードへの修正なしに、テーブルごとのリクエストキャパシティを容易に変更できる。 Amazon DynamoDBはどんなスケールでも完全に管理された経験を提供する Ama
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
