CEDEC 2011で、Amazon Web Servicesエバンジェリストの玉川が利用した資料です。Read less
CEDEC 2011で、Amazon Web Servicesエバンジェリストの玉川が利用した資料です。Read less
※Update! see http://d.hatena.ne.jp/winebarrel/20101023/p1 ap-southeastにMySQL ClusterのAMIを公開しました。 RightScaleのCentOS 5.4のAMIにMySQL Cluster 7.1.5をインストールしたモノです。 管理ノードとSQLノードとデータノードをひとまとめにして、単体で起動するようにしてます。 AMI ID: ami-39c0bf6b Name: winebarrel's MySQL Cluster AMI Image 0.1.0 Description: CentOS 5.4 / MySQL Cluster 7.1.5 MySQL Clusterの起動方法 ログインしてndb_mgmdとndbdのプロセスを起動します。 [root@ip-XXX-XXX-XXX-XXX ~]# /e
大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。 ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。 また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。 ここを解明すべく、各種ベンチマークを実行し
ITproは、Amazon EC2をサービス基盤の一部に利用している。2008年の導入に際しては、ベンチマークテストで実効性能を計測してITpro上で紹介した(関連記事)。2010年3月には再検証を実施し、その結果を書籍「クラウド大全 第2版」に掲載した。今回では、2010年4月に新設されたシンガポールEC2の検証結果を加えた完全版をお届けする。今回は、まず仮想CPUについて取り上げた。 米Amazon Web Services(AWS)のパブリッククラウドサービス「Amazon EC2」は、必要な性能に応じて8種類の仮想マシンを選択できる(表1)。仮想マシンが持つ性能は、演算性能の目安となる独自指標「ECU」や仮想メモリー容量、仮想ストレージ容量などの仕様を明示している。実際の性能はどれほどのものか。ベンチマークで検証した。
MySQLに自動フェイルオーバー機能を追加したAmazonクラウド。オンラインのままパッチ当てやバックアップも クラウド上でMySQLの運用を行うサービス「Amazon Relational Database Service」(Amazon RDS)を提供していたAmazonクラウドは、Amazon RDSに自動フェイルオーバーによる可用性を実現したオプション「Multi-AZ Deployments」を追加したと、ブログ「Amazon RDS - Multi-AZ Deployments For Enhanced Availability & Reliability」で明らかにしました。 データベースの計画停止がなくなる これまでのAmazon RDSは、MySQLがあらかじめインストール済みですぐに利用できると同時に、MySQLにパッチを当て最新に保つとともに、バックアップもしてくれる
計測元は、都内のBフレッツでISPはライブドアプロバイダ。 計測とグラフ描写のコードはここに: http://github.com/hirose31/monitor-latency グラフは、紺色の線がレイテンシの平均値で、水色の範囲は最小値と最大値。 ping RTT まず、ホットなシンガポールのEC2。このグラフだけ、表示期間が1日分。だいたい90msecぐらいですね。 続いてEC2のwestとeast。この2つだけ、計測期間がちょっと古くて2010/3/27のもの。 Amazon EC2 アメリカ西海岸 125msec Amazon EC2 アメリカ東海岸 200msec あとはいろいろ。 ニフティクラウド Google JPIX はてなブックマーク 都内某iDC httping データは httping -c 10 -i 0.7 -r -g TARGET_URLの結果の最小値、平均
「想定以上に使用するサーバー台数が増加する」 「管理コンソールのユーザーインタフェースがミスを誘発しやすい」 「Amazonの都合で仮想サーバーが再起動したことがあった」 「情報がすべて英語で、米本国との交渉が必要」 「クレジットカード払いなのが不便」 同社は2009年初めから、システム開発にEC2の仮想サーバーの利用を開始し、09年10月からは顧客企業向けのサービスもEC2上で稼働した。すでに80台弱のEC2仮想サーバーを利用し、コスト削減効果は3年間で5000万円を見込む。しかも単なるコスト削減にとどまらない効果がEC2にはあると語る。「当社は、マーケティング調査システムを自社開発しており、システム開発ユニットには委託先も含めておよそ20人のエンジニアが所属する。そのエンジニアの雰囲気が良くなったのは、EC2によって開発やテスト用サーバーを潤沢に使えるようになったためだ。当社は中国やフ
公開: 2010年3月28日20時50分頃 「音楽著作権団体らの杜撰なアンケートがフィッシング被害を助長する (takagi-hiromitsu.jp)」というお話が。これはひどいと思いますが、問題は2つありますね。 フォームが別ドメインになっており、その事についての説明がない「個人情報を第三者に提供、委託いたしません」という説明をしておきながら、第三者の管理するサーバに個人情報を送信させている後者に関しては問題としてはシンプルで、単に虚偽の説明がなされているという話ですね。規約とかどうせ誰も読んでない……とは良く言われますが、掲載している本人でさえもロクに読ずにコピペしているのが実情でしょう。確認もしないで嘘を書くくらいなら、最初から書かなければ良いのにと思いますが。 それはそれとして、フォームが別ドメインになっている話は興味深いです。最近は「クラウド」とかなんとか言って外部のサーバでサ
先日のデブサミ2010でも話した(デブサミ2010の資料"クラウドサービスAmazon EC2を活用した「SKIPaaS」構築事例"を公開します+α)のですが、Amazon EC2のサーバからメールを送信すると、一部分の宛先(メールサーバ)では、迷惑メール(SPAM)扱いされ、突き返されちゃう事があります。 それをどう解決したかという話。 Twitterを見ていて、まだきちんとした情報がまとまっていない気がしたので、経験談をまとめてみます。 課題 Amazon EC2のサーバがスパムメール送信に利用されるケースが増えているようで、Amazon EC2で利用されているIPアドレスのレンジ(ネットワーク)が、スパムメールのブラックリストにまるっと載ってしまっているため、メールサーバによっては、門前払いによる受信拒否となるケースがあります。 参考: Amazon EC2を悪用したセキュリティ攻撃
こんにちわ。サービス開発担当の勝間です。クックパッドの1年の最大のピークであるバレンタインが終わり、少し落ち着きをとりもどした技術部からお届けします。 さて、先日秋葉原で「第0回 AWS User Group - Japan勉強会」が開催されました。100人を超す参加者の中、AWSのエバンジェリストJeff Barrさんの講演があったり、内容の濃いLTが続いたりと、非常に大盛況でした。そんなLTに僕も参加して、クックパッドのバッチシステムとAWSとの連携について話してきました。 クックパッドではAWSとしてEC2, S3をつかって分散解析環境を構築して、Hiveを使ったデイリーのログ解析を行っています。LTではそれらの話をしたのですが、5分と限られた時間では駆け足の発表になってしまったので、当日じっくり話せなかった箇所などを確認いただければと思います。 [slideshare id=328
それぞれの特性 基本的に特に断りがない限りSmall Instanceでの話です。エフェメラルドライブやIO速度はInstanceの種類により変化します S3 AMI 利点 基本的にInstanceのみ課金されるので安い 起動するだけで150GBのエフェメラルドライブがついてくる ルートドライブのDiskI/Oが高速(250~300MB/sec) 問題点 起動時にS3からのコピーに時間がかかる ルートドライブが10GBしかない EBS AMI 利点 STOP/STARTを利用する事で高速起動が行える ルートドライブの容量が30GB 起動時に利用出来るドライブオプションが豊富 問題点 ルートドライブのDiskI/Oが低速(60~100MB/sec EBS Volumeと同程度の速度) AMIを起動するだけでEBS Volumeに課金対象が発生する オプションを利用しなければエフェメラル
ITproに2月5日付けで掲載された記事「中古クラウド、あります - 記者の眼」で、高橋秀和記者がAmazon EC2の内部で使われているサーバのCPUが複数種類あることを、調査の上で明らかにしています。 高橋記者はこれまでITproでAmazon EC2での運用を担当してきた経験から、Amazon EC2のデータセンターによってサーバのCPUが異なることに気がつき、起動後の仮想マシンでCPUの種類を確認するコマンドを実行。どのような種類のCPUが使われているかを調べています。 その結果、6種類のCPUが確認できたそうです。記事の表から引用します。 AMD Opteron 270 AMD Opteron 2218 HE Intel Xeon E5345 Intel Xeon E5410 Intel Xeon E5430 Intel Xeon X5550 AMDとIntelの両方を用いており
Amazonクラウドの性能低下を経験したユーザーが、Amazonクラウドはデータセンターのキャパシティを超えて利用者と契約しているのではないか? との疑いを投げかけています。 クラウドは一度使い始めると、現在のところ容易にほかへ乗り換えることはできません。そしてそのクラウドがトラブルに見舞われた場合、利用者自身が問題を解決できる余地はほとんどありません。以下で紹介するのは、実際のトラブルはどうあれ、そうしたクラウドに依存せざるを得ない利用者の立場を浮かび上がらせる話です。 インスタンス性能の低下からネットワークの遅延へ 発端は、Alan Williamson氏による1月12日付けのブログのエントリ「Has Amazon EC2 become over subscribed?」。3年前からAmazonクラウドを利用し続けてきたWilliamson氏は、「Amazonクラウドはまさに限界点を超
EC2を使い始めてはや半年以上が経過した。セキュリティの調査目的、つまりは自分のパソコンではやりたくない作業に使おうと思って契約したのだが、あらためて約款を読んでみると、IDSを動かすのも微妙なのではないかという位にその用途を縛っていることがわかった。 「え?約款て何??」という方も多いと思うが、EC2やS3をはじめとするAmazon AWSを使っている人は例外なく加入時に約款(ユーザーアグリーメント)を承諾しているんです。 これがその実物。http://aws.amazon.com/agreement/ こんな長い約款を読んでいる人なんていないと思うので注意すべき点を書いておく。僕もあまり真面目に読んでないので、このエントリーをみて引っかかった人は是非原文をあたって下さい。 AWSでのご法度/禁則事項 お金を払わないと強制退会になるのは当然として、AWSを使ったDoS攻撃なども全て禁止、
Amazonクラウドを運営するAmazon Web Servicesの日本法人、Amazon Data Services Japanが活動を開始しました。現在、同社には社員が2人在籍し今後さらに陣容を拡大していくと、同社のマーケティングマネージャー 小島英揮(おじまひでき)氏が、昨年の12月25日に行われた「Amazon EC2ユーザ会」で明らかにしました。 Amazon Data Services Japanマーケティングマネージャの小島氏。前職はアドビシステムズでFlashなどのマーケティング担当だった マーケティングマネージャの小島氏がAmazon Data Services Japanに入社したのは昨年の12月。同社にはデータセンターを担当するもう1人の社員がおり、現在さらにテクニカルサポート、ソリューションアーキテクト、営業統括などの役割を担う社員を募集中。「われこそはと思う方は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く