訳：SWF: RightScale でのオーケストレーション事例 by Amazon SWF - aws memo
RightScale Server Orchestration and Amazon SWF launch | RightScale Blog http://blog.rightscale.com/2012/02/22/rightscale-server-orchestration-and-amazon-swf-launch/ 超意訳 ＝＝＝＝ Amazon SWFのリリース (Wernerのブログも参照のこと）は、我々が手がけている新しい自動化機能について語る良い機会であり、来るべきリリースを提示するだろう。我々はすでに数カ月の間、サービスのバックエンドでSWFを使っており、SWFはオーケストレーション機能の開発をものすごく加速させる極めて素晴らしいサービスである。個人的には、自動化は、クラウドコンピューティングにおいて最も基本的な進化と思う。自動化によって、すべてのビジネス的な利便性（
訳： AWSで高可用性を実現するベストプラクティス - aws memo
AWS Cloud Best Practice: Introduction to High Availability Deployment | Newvem AWSのアーキテクチャセンターにも図があるが、解説が少ないので、このシナリオ・ステップは参考になるだろう。 しかし、インフラがRoute53でリージョン間冗長性を考えるグローバルスケールになりつつある中、1台のサーバのRASとか1ラック内のサーバ2台の可用性という小さなインフラしか考えられないガラパゴスな日本人は間違いなく置いて行かれるな。。 ＝＝＝ 最初にAWSにアプリケーションをデプロイすることは難しい。たくさんの新しい用語と概念を理解する必要がある。AWSに最初のインスタンスを起動する前に、全てのAWSの選択肢を理解する必要がある。 本稿は、AWSのインフラで高可用性( High Availability , HA)を実現するア
訳：Netflixが 6.29のAWSと嵐から学んだこと - aws memo
2012年6月は、立て続けにUS EASTリージョンでダウンタイムが発生している。 NetflixのようにマルチAZの構成にして、常に擬似的に障害を発生させる仕組み( Chaos Monkey)を導入していても、ダウンする場合があることが明らかになった。さらなる可用性向上のためのツール(Chaos Monkey Family)やアーキテクチャ設計ノウハウがNetflixから出てくることを期待。 The Netflix Tech Blog: Lessons Netflix Learned from the AWS Storm ＝＝＝ 概要 2012年6月29日(金)、ここ1年で最も大きな停止障害を経験した。太平洋時間午後8:00に始まり、復旧まで約3時間かかり、アメリカのNetflix会員に影響を及ぼした。弾力性のあるインフラに向けた努力にとAmazonクラウドでの経験をよく書いている。過去
訳：どのようにしてVimeoはEC2の費用を50%削減したか - aws memo
これは面白い記事。 High Scalability - High Scalability - How Vimeo Saves 50% on EC2 by Playing a Smarter Game ＝＝ ビデオトランスコーディング処理用のEC2インスタンス費用を、スポットインスタンス、オンデマンドインスタンス、リザーブドインスタンスを賢く組み合わせることで50%も費用を削減している。 Vimeo on EC2 を見るとその考え方がわかる。この資料は2011年のものだが、リザーブドインスタンスマーケットができたので、彼らの戦略も変わってくるだろう。 Vimeoのアプローチは 閾値以上にbidしない。閾値はオンデマンド価格の80%に設定 いかなるときも、 10以上のスポットリクエストを出さない １時間前の平均価格より10%高くbidする 非ピーク時の負荷に必要なぶんだけリザーブを買う 優先
EIP : EC2とVPCでの相違点 - aws memo
Differences Between EC2 Addresses and VPC Addresses ( in Elastic IP Addresses - Amazon Virtual Private Cloud) けっこう違いが大きい。特に、EIPをフローティングIPとして使ってHA的な作り込みをする際には注意が必要。(移す場合は、お作法として一旦disassociateすべきか？） EC2VPC アドレスを確保すると、AWSアカウントに紐付けられるが、VPCの外でしか使えない。 アドレスを確保すると、AWSアカウントに紐付けられるが、VPC内でしか使えない あるインスタンスに関連付けられているアドレスを別のインスタンスに関連付けようとすると、自動的に新しいインスタンスに関連付けられる。 あるインスタンスに関連付けられているアドレスを別のインスタンスに関連付けようとすると、その要求は
訳：EBS : Snapshotの仕組み等 - aws memo
2012.02.12追記 @ayakomuro さんがわかりやすく解説してくれている。 popowa: EBSのスナップショットについて ----- Amazon’s Elastic Block Store explained | RightScale Blog スナップショットバックアップは、EBSの機能の中でも、最も便利で最も理解が難しい機能である。EBSボリュームのスナップショットはいつでも取得可能である。すべてのS3上のデータと同じく、ボリュームのデータのコピーをS3に保存する。最初の特徴は、スナップショットはユーザのS3バケツに表示されないこと。そのため、標準のS3 APIでアクセスできない。EC2 APIでスナップショットの一覧を取得できる。また、スナップショットから新しいボリュームを作成することでリカバリ可能。２番目の特徴は、インクリメンタルスナップショットであること。これは
RDS : Storage容量の内訳について - aws memo
RDSは、起動時および停止中にストレージサイズを変更可能。 ストレージの空き状況も、CloudWatchのFreeStorageSpaceで確認可能。 では、Storageには何がはいっているのか？ https://forums.aws.amazon.com/thread.jspa?threadID=75508 The storage space used by your instance does not include the MySQL or Oracle binaries, but does include the databases, innodb log files, binlogs, and the InnoDB tablespace (ibdata1, which grows automatically) and log files which are usually sm
訳：ELB：評価方法のベストプラクティス - aws memo
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services http://aws.amazon.com/articles/1636185810492479 ＝＝＝＝ 概要 ELBを最もよく評価するには、ELBのアーキテクチャを理解する必要がある。本稿は、AWS ELBの機能と独特なアーキテクチャについて述べる。ベストプラクティスを提供することで、ELBをテスト・評価する際に一般的な落とし穴(pitfall)から避けられるようになる。このホワイトペーパーが対象としている読者は、ELBの経験が少ないが、過去にH/W,S/Wのロードバランサを使ったことがあるような開発者である。 ELBの概要 ELBは、複数のEC2インスタンスへ、自動的にトラフィックを分散する。単
EBS: Provisioned IOPSの性能・ベンチマーク - aws memo
そのものずばりのページが、EC2のドキュメントにあるので、メモ。 Increasing EBS Performance - Amazon Elastic Compute Cloud 性能を出すには RAID0かRAID1+0 (RAID10) でストライピング 平均キューレングスをチェック EBSボリューム利用前にプリロード(※)しておく EBS-Optimized インスタンスを使う とか。 プリロード $ dd if=/dev/sdf of=/dev/null をやっておく。（と上記URLにも書いてある） ベンチマーク PIOPSは、ブロックサイズ16KBなので fioをかけるときも --bs=16kをつけている fio --directory=/media/p_iops_vol0 --name fio_test_file --direct=1 --rw=randwrite --bs
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
AWS: JavaのDNSキャッシュ ( TTL )について - aws memo
AWSのサービスではDNSを用いて可用性を向上する仕組みを用いている。 各種APIのエンドポイント RDSのエンドポイント ELBのエンドポイント ElastiCacheのエンドポイント CloudSearchのエンドポイント Redshiftのエンドポイント などなど。AWSが提供するエンドポイントのFQDNを、自分のアプリケーションから参照するように設定したり、一旦DNSでCNAME設定することも多い。 ただし、これらのエンドポイントFQDNで設定されているIPアドレスは、運用中に変更される可能性がある（ノード障害、フェイルオーバー等によるIPアドレス変更、スケーリングによるIPアドレス増減、等）。そのため、アプリケーション側はエンドポイントのIPアドレス変更に追随する必要がある。（追随しないと、古いIPアドレスにアクセス試行しつづけて、結果としてシステム障害になってしまう） ここで問
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
EC2: インスタンス起動を速くする - aws memo