« 2010年10 月 | メイン | 2010年12 月 »
AWSスタートアップチャレンジの今年のファイナリストが発表されています。いずれも選抜を勝ち抜いてきた素晴らしいアイデアの数々です。選抜されたファイナリストはシリコンバレーに招待され、12/8のファイナルにて、優勝をめざして競い合います。ファイナリストの皆様、本当におめでとうございます！！
アルファベット順でファイナリストのご紹介:
各チームの詳細については、下記をご参照くださいませ。
Amazon Web Services Blog: AWS Start-Up Challenge 2010 Finalists
玉川憲
Twitter: @KenTamagawa
Fedoraコミュニティは11月上旬に Fedora 14をリリースしています。その際に、EC2のAmazon Machine Image(AMI)を同時にリリースしています。
これは非常に大きなニュースで、Fedoraは最も有名なLinuxディストリビューションの一つで数百万のFedoraが世界中で動いています。新しいバージョンのFedoraは、新しい desktop, system administration, developerなどの機能を持っています。
6か月ほど前は、カーネルの互換性が無かったために前のバージョンのFedoraをクラウドで動かすことはできませんでした。今回のリリースから、FedoraチームはEC２を最も重要なプラットフォームとして捉え、リリースの際にサポートしなければいけないプラットフォームとして扱って頂いているということですね！
Fedora 14のAMIのIDはこちらです。ログインの際は、rootではなく、ec2-userを使ってください。ちなみに、現在のAMIは全てinstance store(S3からブートされるもの)のようですが、EBS backedのものもcoming soon!なようです。
玉川憲
Twitter: KenTamagawa
もしデスクトップPCの中に高機能なビデオカードが入っているなら、それはおそらくGPU(Graphics Processing Unit)とよばれる特殊なプロセッサを含んでいるでしょう。GPUの命令セットとメモリ構造は、複雑なグラフィックスを高速に表示するのに必要な数々の関数を処理するように設計されています。それらの命令セットは、2次元や3次元の座標を操作する命令や、より複雑な計算を実施するための命令を含んでいます。また、GPUのアーキテクチャは座標点の長いストリーム(一般的にベクターと呼ばれる)を効率的に処理できるように設計されています。これは深いパイプライン構造をとり、メモリの幅広い領域に高速にアクセスする必要があります。
数年ほど前から、数量計算や化学計算を行う先進的な開発者が、GPGPU(General-Purpose computing on Graphics Processing Unites)と呼ばれる汎用的な計算処理を行うためにGPUを使うようになってきました。
多種のアプリケーションへの要望が高まるにつれて、アプリケーション開発における高速な倍精度浮動小数点処理やECC(Error Checking and Correcting)メモリなどへのニーズは、進化したGPUテクノロジとマッチしはじめたのです。しかし、HPCクラスターのようなハイエンドなテクノロジは、多くの開発者にとってはこれまで高根の花であり、垂涎の的でした。
今回の発表では、新しいEC2のインスタンスタイプとして、クラスターGPUインスタンスを導入いたしました(これで合計11のインスタンスタイプとなります)。いまや、全てのAWSユーザが、経済的コストかつ従量課金モデルで、GPGPUを用いた開発・運用が可能となります。
先日発表いたしましたクラスターコンピュートインスタンス(APIで呼び出す際にはcc1.4xlarge)に比較的近いものになりますが、クラスターGPUインスタンス(APIで呼び出す際にはcg1.4xlarge)は次のスペックとなります:
個々のTesla M2050は448コア、3GBのECC RAMを含み、倍精度浮動小数点演算で515gigaflopsまで可能です。1つのインスタンスが2つのプロセッサを含むので、クラスターGPUインスタンスあたり1兆FLOPSを上回るパフォーマンスを発揮します。 10Gbpsのイーサネットでこれらのインスタンスをクラスタリングできるので、並列計算、レンダリング、メディア処理に最適です。まらに、クラスターGPUインスタンスは、「数百メーターに渡って一気に地面をならすことのできる核エンジンを持ったブルドーザー」のイメージです。しかも、それが時間あたり約172円(1$82円換算)で使えるのです！
AWSアカウント一つにつき、デフォルト設定では8個のクラスターGPUインスタンスを使うことができます。もしそれ以上に必要な場合は、こちらからAWSにご連絡ください。この制限は技術的な制限ではなく、我々がこの発表に対する皆様のご要望を早期に理解するのに役立ちます。実際に、クラスターコンピュートインスタンスもこのような制限を設けさせて頂いておりましたが、現時点ですでにこの制限は取り除いており、最大128インスタンスまで立ち上げられるようになっています。
GPUにおいて最大のパフォーマンスを発揮するには、専門化したコードを開発する必要があります。Tesla GPUは、 CUDAアーキテクチャを実装しています。インスタンス上で最新のNVIDIAドライバをインストールすることで、Tesla GPUを様々な場面で利用することができます:
Elastic MapReduceにおいても、クラスターコンピュートインスタンスと、クラスターGPUインスタンスを利用することができ、Hadoopの大量並列計算アーキテクチャとハイパフォーマンスコンピューティングを組み合わせて利用可能です。Elastic MapReduceがワークロード並列化、ノード設定、スケーリング、クラスター管理などの面倒をみてくれるので、開発者はアプリケーションレイヤに集中することが可能となります。
GPUやGPUプログラミングについてのより詳細な情報は以下になります:
いかがでしょうか？皆様のアプリケーションでこの「ブルドーザー」を利用できそうでしょうか？こういった計算能力を手にすることが出来た今、皆様だったらどんなことにチャレンジされるでしょうか？是非、このブログにコメントを残してくださいませ！！
玉川憲
Twitter: KenTamagawa
いきなりですが、幾つか質問してみても宜しいでしょうか？
Amazon S3でアップロードする際に、特に、50MB~100MB以上のサイズのオブジェクトをアップロードする際には、そのスピードや安定性に関してはまだまだ改善の余地があることを我々のチームは認識しておりました。大きなサイズのオブジェクトをアップロードするのをより簡単にするために、このたび、マルチパートアップロード機能(Multipart Upload)を発表しました。
この発表により、大きなオブジェクトを分割して小分けし、小分けオブジェクトを並列にアップロードすることが可能です。もし、小分けしたオブジェクトのアップロードが失敗した際には、単純にその小分けオブジェクトを再アップロードできます。並列にアップロードすることで、全体のアップロードスピードを向上できます。例えば、全体の長さが決まっていないようなストリームのデータを受信(もしくは作成)しているような場合でも、全てのデータを入手する前にアップロードを開始するようなことも可能になるでしょう。
この新しい機能を使うことで、5GBのオブジェクトをアップロードする際に(5GBはS3における現時点での1ファイルの最大サイズ)、個々のファイルサイズが5MB以上に、最大1024個のファイルに分割できます。分割されたオブジェクトは、アップロードに失敗した場合、他の分割オブジェクトに影響を及ぼすことなく再アップロードできます。全ての分割オブジェクトをアップロードすると、S3に全オブジェクトを統合するようなコールを投げることが可能です。
以下が、今回の機能を使うにあたってアプリケーション側の手順は以下の通りです:
「３．アップロード」の際には、各パーツを順番にアップロードすることも可能ですし、複数パーツをを一度に並列にアップロードすることもできます。(前者は、インターネット接続で断続的であったり不安定な場合に向いているでしょう。後者は十分なネットワーク帯域がある場合に向いているでしょう。)もし、並列アップロードをする際には、list partsオペレーションを使うとアップロード状況をリストアップすることが可能です。
これからも、分割、マルチスレッド、リスタートなどの便利なロジックが様々なツールやライブラリに組み込まれていくことを期待しています。もし皆様がツール開発者、もしくは、ライブラリ開発者で、作ってしまいました、ということでしたら、是非このブログにコメントしてください！！
玉川憲
Twitter: KenTamagawa
Amazon CloudFrontは、世界に拡がるエッジロケーションを使用し、ユーザがどこに住んでいようとも、高速で低遅延のコンテンツ配信を可能にするクラウドサービスです。
これまで、CloudFrontはAmazon S3のデータを基にコンテンツ配信を行うことができました。コンテンツ配信の業界用語でいうと、S3が唯一のオリジンサーバ(Origin Server)でした。Webページ、スタイルシート、画像、JavaScriptなどのオブジェクトをS3に保存し、CloudFrontにおいて配信(ディストリビューション)と呼ばれる設定を作成すると、東京を含む世界16か所(2010年11月9日)のエッジサーバーにオブジェクトをキャッシュして世界中のユーザに高速配信が開始できたのです。
本日より、CloudFrontにおいて、お好みのオリジンサーバをお使い頂けるようになりました！
ユーザ指定のカスタムオリジンを利用して、CloudFrontディストリビューションを作成することが可能になったのです。各ディストリビューションにおいて、オリジンとして、S3を指定することも、カスタムオリジンを指定することも可能です。カスタムオリジンとして、他のストレージサービスを使うことも可能ですし、よりダイナミックに、EC2インスタンスやElastic Load Balancer(ロードバランサ)を用いることもできます。
CloudFrontの裏で動的な処理ができるようになったので、ストレージ、キャッシュ、グローバル配信を心配することなく、コンテンツをオンデマンドに作成することが可能になります。外向けには静的に見えるコンテンツ(URLが紐付いている)でも、必要なときにその場で作成して配信することができます。
こういった機能は、再利用可能だけれども、頻繁に変更され、かつ、作成するのは手間がかかる、といった性質のコンテンツを扱うのに非常に便利です。例えば、基本となる地図上に、幾つかのカスタムレイヤーをオーバーレイする、マップタイルなどは良い例といえます。マップタイルの全てのコンビネーションを作成しておくのはコストがかかりすぎますし、一度使ったタイルはもう一度使われることは少ないでしょう。代わりに、タイルを作成する際に必要であったパラメータを、個々のタイルのURLのpathコンポーネントに含ませておき、タイルがすでに特定のCloudFrontのエッジロケーションに存在していればそれを利用し、存在していなければ作成してエッジロケーションに保存して利用する、という処理を行うことになるでしょう。
CloudFront Developer Guideの最新バージョンでは、カスタムオリジンの使用に関するガイドラインを含んでいます。重要なものを以下に抜き出しましたので、ご参考までに：
下記のツール、ツールキット、アプリケーションはすでにこの新しい機能をサポートしています:
他のAWSの新機能と同様に、我々がこの機能を実装したのは、お客様からのご要望の声があったからです。もし、ほかにアイデアやご要望がありましたら、AWSフォーラム(日本語、要AWSアカウント)、JAWS-UGフォーラム、CloudFront discussion forum(英語)、もしくはこのブログへのコメント、どちらでも構いませんので、是非宜しくお願い致します。耳をダンボにしてお待ちしております。
玉川憲
Twitter: @KenTamagawa
このブログ内の記事を検索
