BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース スマートクライアント・Dumbサーバを実現?AWSがWebブラウザのJavaScript向けSDKをリリース

スマートクライアント・Dumbサーバを実現?AWSがWebブラウザのJavaScript向けSDKをリリース

ブックマーク

原文(投稿日:2013/11/07)へのリンク

ここ数年、開発者は何らかの力仕事をサーバサイドのコードに頼り続けていたものの、クライアントサイドのコードにより多くの仕事をするよう求めていた。AWSは、ブラウザからAWSのサービスへの安全なアクセスを行うJavaScript SDKのリリースによって、そのモデルを刷新している。これにより、いくつかのケースでは、サーバサイドのコードをまったく必要としなくなっているのである。

開発者プレビュー版をアナウンスしているブログ記事の中で、AWSチームはSDKがサポートしている4つのAWSサービスについての概要を述べた。

開発者は下記のAWSサービスを直接呼び出すことが可能です。

  • Amazon S3:任意の規模でオブジェクトの格納と取得を行う
  • Amazon SQS:読み出しと書き込みをメッセージキューに対して行う
  • Amazon SNS:モバイル端末およびその他の分散サービスに対する、通知の生成と処理を行う
  • Amazon DynamoDB:任意のアクセス速度で、あらゆる量のデータを格納・取得する

SDKは、上述の各サービスが提供している全機能へのアクセスをサポートしています。開発者はS3のバケットの生成とデータ追加、メッセージキューの管理、生成、追加、そしてDynamoDBのテーブルへの問い合わせなどなど、その他さまざまなことができます!

一部のアプリケーションにおいては、この機能はWebサーバの必要性を完全に排除することができるだろう。Amazon S3は静的なWebアプリケーションのホスティングをサポートしており、Webサイトをバケットにアップロードし、Webに公開することを可能にしている。静的なアプリケーションはS3Dropboxといったサービスや、nginxのようなハイパフォーマンスのHTTPサーバを通じて簡単に拡張することができる。

ソフトウェア業界の草分け的存在であるDave Winer氏は、このリリースについて楽観的であり、我々が『真の技術的ブレークスルー』の最前線にいると考えている。Webサービスをコールし、リクエストをさばくためのスケールを要するプロキシサーバを構築する代わりに、静的なアプリケーションの開発者は、必要な規模を提供してくれるWebサービスプロバイダだけに頼ることが可能である。Dropboxはこのモデルを2012年に採用しており、そこにWiner氏はこれからの未来を見出した。

そして1年以上前、Dropboxは驚くべきことを行いました

基本的に彼らは中間サーバを構築する必要をなくすために、プロキシサーバの機能をdropbox.comに吸収しました。それにより、ある日突然、Dropboxに接続するアプリのためにサーバソフトウェアのコードを書く必要はなくなります。スケーリング問題はフッと消えてしまいます。資金調達、もしくはユーザを広告主に売る必要も。

スケーリングは引き続き行われなければなりません。しかし、それはDropboxによって行われます。彼らはそれを広告主にユーザーを売ることによってでなく、むしろ彼らのサービスを利用するユーザに請求することによって行うのです。完璧ですね。このような経済は、まさしく正しいと感じます。

Winer氏は、競合他社もこのモデルに追随することを強く勧めていたため、このAWS SDKの発表を知り、喜んだ。

Dropboxが行ったようなことを実施するよう強く勧めるために、私は競合他社のあらゆる人と話してきました。そのうちたった数社でも実現すれば、―私は説得しました―普及率はすぐにクリティカルマスに達し、その後いくつかの本当に面白いことが起こるでしょう。あらゆる種類のアプリケーションに適用可能です。悲しいかな、それはどこも実現しませんでした。―AmazonがWebブラウザのJavaScript向けAWS SDKを発表した、昨日までは。理論的には、Dropboxと同様に、これは彼ら自身のためのWebサービスと言えるでしょう。彼らの主張としては、開発者が今までプロキシを必要としていたような何がしかのことを行うために、直接彼らのサーバをコールすることができるというものです。

公開されたすべてのWebサービスが認証の仕組みを持つとは限らないが、AWSは確実にその仕組みを持っている。AWSは、単純なクライアントサイドアプリケーションにおける認証の課題に、どのように取り組んだのだろうか?

過去にAWSのSDKとAPIを使ったことがあれば、各リクエストにAWS credentilasによる署名が必要ということはご存知かと思います。誰にでも見られ、使われる可能性があるHTMLやJavaScriptに、あなたのcredentilasを含めたくないはずです。その代わり、あなたのアプリケーションのユーザを認証するために、WebのID連携を使用しなくてはいけません。WebのID連携をアプリケーションに組み込むことにより、一時的なセキュリティ証明書のセットを発行するにあたって、公開認証プロバイダ(FacebookGoogleもしくはLogin with Amazonサービス)を使用することができます。

AWSのIdentity and Access Management(IAM)サービスは、定義済みのロールを引き継いでユーザを認証できるよう、個別の認証プロバイダでアプリケーションを登録できるようにするものである。彼らが最近リリースしたWeb Identity Federation Playgroundでは、認証のインタラクションのシミュレーション、および出力結果の確認が簡単にできるようになっている。このサービスは、AWSリソースに対する認証ポリシーを作成し、ユーザがアクセスするシナリオをテストしたい開発者を支援するものとなるだろう。

AWSの典型的なやり方にならって、SDKを学ぶ専用のWebサイトや、基本的なハウツーもののウォークスルー、そしてサポートフォーラムがすでに用意されている。最初にサポートされたサービスはあくまでAWSファミリーの一部に過ぎないが、ストレージやメッセージングのような性能を必要とするアプリケーション開発者を対象としている。今後、さらなるサービス―ElastiCache、Simple Email Service、もしくはEC2も―のサポートがSDKに追加されることを期待するのは、理不尽なことではない。

この記事に星をつける

おすすめ度
スタイル

BT