AWSがクラウドのインフラストラクチャをさらに拡張、AMD EPYCを使うT3aインスタンスを供用開始

Amazonは常に、AWSを使っているデベロッパーに提供するオプションを増やそうとしている。そして米国時間4月25日、同社はそのためにAMD EPYCプロセッサーによるT3aインスタンスを数多く発表した。これらは最初、昨年のデベロッパーカンファレンスre:Inventで発表された。

しかし今日のは、その一般供用の開始を告げる発表だ。それらはバーストのある特殊なタイプのワークロードに適したインスタンスで、ユーザーの通常の計算力のニーズはそんなに、バースト時ほど高くはないというものだ。

AWSのJeff Barr氏がブログにこう書いている。「これらのインスタンスはバーストに対応できる費用効率のいいパフォーマンスを提供し、常時維持されるコンピュートパワーとしてはそれほど高いパワーを必要としないが、使用時に一時的なスパイクがあるワークロードに適している。そのため、十分に余裕のある、確実に保証されたベースラインの処理能力を提供するとともに、さらなる処理能力が必要なときには、必要十分な時間、完全なコアパフォーマンスにまで透明にスケールアップする能力がある」。

これらのインスタンスは、Amazonが数年かけて開発した特製のネットワーキングインタフェイスハードウェアAWS Nitro Systemを使用する。このシステムの主要な部位は、Nitro Card I/O Acceleration、Nitro Security Chip、そしてNitro Hypervisorだ。

今日のリリースの前身として、昨年発表されたArmベースのAWS Graviton Processorsを使用するEC2インスタンスがある。これもまた、スケールアウトするワークロードのためのソリューションを探しているデベロッパー向けのオプションだ。

さらにこの直前の先月には、低コストのAMDチップを使用するM5およびR5インスタンスが発表された。これらもやはり、Nitro Systemを基盤としている。

EPCYプロセッサーは今日から7つのサイズで可利用になり、必要に応じ、ユーザーが選んだスポットインスタンスやリザーブドインスタンス、あるいはオンデマンドインスタンスで提供される。可利用域はUS East(Northern Virginia)、US West(Oregon)、EU(Ireland)、US East(Ohio)、そしてAsia-Pacific(Singapore)だ。

画像クレジット: Thomas Cloer/Flickr CC BY-SA 2.0のライセンスによる

関連記事: AWSはアグレッシブに世界制覇を目指す――エンタープライズ・コンピューティングで全方位路線

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

AmazonがAlexaのスキルを作れるデベロッパーの資格証明制度を立ち上げ、企業ニーズに応える

Amazon EchoなどのAlexaデバイスを作っているデベロッパーに、自分の能力を証明する新しい資格証明制度として、AWS Certified Alexa Skill Builder – Specialtyというものが立ち上げられた。Amazonによると、同社がAlexaデベロッパーのための資格証明を提供するのは、これが初めてである。

資格証明はテクノロジー業界ではよくあり、AmazonのAWSもすでに教育訓練事業とともに独自の資格証明を提供して、企業がAWSの知識とクラウドの専門的技能を持った技術者を確実に雇用できるようにしている。

今回のAlexa技術の資格証明はAWSの資格認証事業の一環となり、その人がAlexaの音声アプリ開発のすべての側面を正しく理解していることを確認する。

検証されるのはアプリケーションの開発や試験の仕方、スキルの検査とトラブルシューティング、Alexa Developer Consoleの使い方、Alexaのスキルのオペレーションとライフサイクルの管理など、実践的な要素が多い。また、声の価値や、音声のユーザー体験のあるべきフロー、など、今多くのAlexaデベロッパーが悩んでいるような高レベルのコンセプトの知識も試される。

試験のガイドがあるので、これを見ると、スキル習得のために勉強すべきチュートリアルや技術的ドキュメンテーションなどがわかる。またオンラインのトレーニングコースもある。

準備万端でこれから試験を受けようというデベロッパーは、AWS Trainingのアカウントを取得して、試験のスケジュールを決める。

Amazonが主張する目標は、今日市場に存在する1億以上のAlexa対応デバイスの顧客の心をつかむような、魅力的な音声アプリ体験を作る機会を、もっと多くのデベロッパーに提供することだ。

つまりAmazonが求めるのは、デベロッパーがAlexaのスキル開発をちょっと浅く体験するだけでなく、そのベストプラクティスも身につけて、顧客に対し強い訴求力を持つアプリケーションを作ってもらうことだ。

この資格証明事業はスマートスピーカーがここ米国でクリティカル・マスに達したそのほぼ同じタイミングで展開される。でもサードパーティのスキルはまだ、大ヒットに乏しくスマホのアプリストアほどの人気を獲得していない。それはBloombergが最近報じたとおりだ。

音楽やタイマー、スマートホームのコントロールなどはスマートスピーカーのヒットと言えるかもしれないが、でもそれらは、ネイティブの(最初からある)ファンクションだ。消費者の採用が今後伸びないなら、今80万以上あるサードパーティのAlexaスキルの将来性も危うい。

しかしそれでも、企業は今でもこのプラットホームに強い関心を持っている。なんといっても、Alexaの大きなインストールベースは魅力だ。今でも毎日、1日に1つは、どこかの企業がスキルを発表している。今日のそれは、赤十字だった。

AWSで資格証明と教育訓練事業を担当しているディレクターKevin Kelly氏が、声明の中でこう言っている。「音声アプリ(Alexa用語では“スキル”)を作れる有能なプロフェッショナルは、最近ますます多くの企業から求められている。この新たな資格証明はAlexaにフォーカスした唯一の認証制度として、そういうプロフェッショナルなスキルを検定できる」。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

ML/AIプラットホームのVizion.aiがマネージドElasticsearchサービスを立ち上げ

オープンソースの分散検索エンジンのElasticsearchは、今や大小さまざまな多くの企業が自社の分散検索とアナリティクスを実装するために利用している。そのセットアップはそれほど困難ではないが、難しいのはリソースの最適プロビジョニングだ。特にユーザーの要求にスパイクがあるアプリケーションでは無駄のないリソース確保が難しい。そこで、Elasticsearchを管理を伴うクラウドサービスElasticsearch Serviceとして提供するVizion.aiは、その心配を解消し、ユーザーが実際に使ったインフラストラクチャにのみ課金する。

Vizion.aiのサービスは、必要に応じて自動的にスケールアップ・ダウンする。そのマネージドサービスとして提供されるSaaSプラットホームはプライベートとパブリック両様のクラウドデプロイをサポートし、Elasticの標準的スタックとの完全なAPI互換性がある。また標準のツールとして、データ視覚化のKibanaや、データをサービスに送るBeats、入力データを変換してデータパイプラインをセットアップするLogstashなど、Elasticsearchの標準のツールも含まれている。例えばーザーは、テスト用や開発用に複数のスタックを容易に作ることができる。

Vizion.aiのGeoff Tudor氏

Vision.aiのバイスプレジデントでゼネラルマネージャーのGeoff Tudor氏は、次のように語る。「AWSのElacticsearchサービスを使おうとすると、選択肢の数が多すぎて途方に暮れてしまう。インスタンスのサイズはどれにするか?、インスタンスはいくつ必要か?、地理的冗長性は必要か?、どんなネットワーキングを使うのか?、セキュリティはどうか?、などなど。選択を間違えると全体的なパフォーマンスに影響が及ぶ。弊社では、インフラストラクチャのレイヤの背後でリソースの均衡化を動的に行う」。

そのためにこのサービスはユーザーの利用パターンを見て、そのユースケースに合った最適なリソース割り当てを行う。実はVizion.aiの親会社Panzuraはエンタープライズ向けのマルチクラウドストレージサービスで、データのキャッシングに関する多くのパテントを持っている。今度の新しいElasticsearchサービスは、それらの技術を利用してリソースの最適割り当てを行う。

Tudor氏も認めるように、Elasticsearchの商用サービスはほかにもある。それらと、Vizion.aiの新しいサービスとの差別化要因は、事前にメタデータ用のストレージのサイズを決めなくてもよいこと、そして高価なSSDを大量に使わないことだ。PanzuraのIPを利用できるVision.aiは、最近のデータだけをSSDにキャッシュし、そのほかは安価なオブジェクトストレージのプールに収める。

さらに彼によると、Vizion.aiはAIやMLのワークロードを動かす総合的なサービスであり、Elasticsearchサービスはその構成成分のひとつだ。TensorFlowやPredictionIOのサポートも、目下準備中だ。とくにPredictionIOは、Elasticsearchと併用しやすい。「今後これを、マルチクラウドによる使いやすいサーバーレスのML/AIサービスにしていきたい。しかもうちでは、提供するのはコンピュート(計算処理)だけではなく、レコードのストレージも非常に高いコスパで利用できる」。

[原文へ]

(翻訳:iwatani、a.k.a. hiwa

企業のAI利用の前進と成長を助けるPeltarionが$20Mを調達

SpotifyやSkype、King、TrueCaller、Googleなどの元役員たちが創業したスウェーデンのPeltarionが今日(米国時間2/14)、シリーズAで2000万ドルを調達したことを発表した。このラウンドをリードしたEuclidean Capitalは、ヘッジファンドの億万長者James Simonsのファミリーオフィスだ。これまでの投資家FAMとEQT Venturesも参加し、このラウンドで同社の調達総額は3500万ドルになる。

もちろん、今の世の中、AIプラットホームに不足はない。そんな中でPeltarionは、“オペレーショナルAI”と同社が呼ぶものに特化している。そのサービスは、データの前処理からモデルの構築、それらのプロダクションへの導入など、企業がAIを利用する場合のあらゆる局面を支援するエンドツーエンドのプラットホームだ。このすべてがクラウドで動き、デベロッパーはグラフィカルなユーザーインタフェイスから自分のモデルの構築と試験を行なう。これに関しとくに同社が強調するのは、Peltarionのユーザーは低レベルのハードウェアやソフトウェアをいっさい扱う必要がなく、ひたすらモデルの構築にフォーカスできることだ。

PeltarionのCEOで協同ファウンダーのLuka Crnkovic-Friisは次のように説明する: “オペレーショナルプラットホームの上でAIシステムを構築しデプロイすると、そのスピードはTensorFlowなどの業界標準のツールを使った場合に比べて桁違いに速い。所要人員もはるかに少ないし、AIの高度な専門知識も要らない。それによって、これまでよりもずっと多くの企業がAIを運用でき、問題解決と変化の創成に集中できるようになる”。

しかし企業の選択肢がとても多い今の時代に、わざわざ無名に近いPeltarionを選ぶ理由はあるだろうか? Crnkovic-Friisはこう語る: “うちのクライアントのほぼ全員が、特定のクラウドプロバイダーへのロックインを心配している。ストレージやコンピューターを使うだけならどのプロバイダーも似たようなものだし、他のプロバイダーへの移行もできる。しかし彼らがとても心配しているのは、AWSやGCP、Azureなどのプロバイダーが提供しているさまざまな高レベルのサービスだ。それらが、完全なロックインを作り出す”。

もちろんPeltarionは、そのプラットホームがユーザーをロックインしない、と主張する。また、他のプラットホームは、個々の企業のオペレーションのヘルプではなく、自らの商用製品としてのAIサービスを作るためにAIの専門技術を大量に使っている、という。確かに同社の言うとおり、大手テクノロジー企業以外では、多くの企業がAIのスケーラビリティで苦戦している。“彼らはスターティングブロックの上で止まってしまう。二つの大きなバリヤがあるので、走り出せない: 未熟なパッチワーク的技術と、スキルの不足だ”、とCrnkovic-Friisは述べる。

同社は新たな資金を、開発チームの増員と、コミュニティやパートナーと協働できるチーム作りに向けていく。また、アメリカなどそのほかの市場における成長にも、充てていきたい、という。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSがハードウェアレベルのコントロールを必要とする顧客のためにベアメタルインスタンスを提供

Infrastructure as a Service(IaaS, サービスとしてのインフラストラクチャ)といえばそれは通常、マルチテナントの環境に存在する仮想マシンを、お金を払って利用することだ。つまりそれは、一定の共有リソースを使用する。多くの企業にとってはそれでも十分だが、もっと独自のコントロールをしたければ、他のユーザーに共有されない、全体を自社でコントロールできるハードウェアリソース一式が収まっている、シングルテナントのシステムを選ぶだろう。このやり方のことを、業界用語で“ベアメタル”と呼ぶ。そして今日AWSは、新たに5種類のベアメタルインスタンスを発表した。

このようなサービスはひとつの物理サーバーをユーザーが独占し、プロセッサーやストレージなどのリソースを自分でコントロールすることになるので、料金は高くなる。でもこれは一連のプロダクトの一部であり、すべてのクラウドベンダーが提供している。ユーザーは、ふつうの仮想マシンを使って、ハードウェアのコントロールほとんどなしを選んでもよいし、あるいはベアメタルを選んでハードウェアを細かくコントロールしてもよい。どちらにするかは、クラウドに載せるワークロードの性質や目的による。

この新しいインスタンスを発表するブログ記事でAWSは、具体的なユースケースを述べている: “ベアメタルインスタンスでEC2の顧客は、詳細なパフォーマンス分析ツールを利用するアプリケーションや、ベアメタルのインフラストラクチャへの直接アクセスを必要とする特殊なワークロード、仮想環境ではサポートされないレガシーのワークロード、そしてライセンス制限のあるティア1のビジネスクリティカルなアプリケーションを動かすことができる”。

5種類のベアメタルインスタンスはそれぞれm5.metal、m5d.metal、r5.metal、r5d.metal、およびz1d.metalと呼ばれ(憶えやすい名前だねAmazonさん〔皮肉!〕)、さまざまなリソースを提供する:

チャート提供: Amazon

これらの新しいプロダクトは今日(米国時間2/14)から、ユーザーの要求に応じて、オンデマンドインスタンス、リザーブドインスタンス、またはスポットインスタンスとして提供される。

関連記事: WTF is cloud computing?…クラウドコンピューティング入門(未訳)

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

MLのモデルをチューニングするオープンソースのツールNeo-AIをAWSがローンチ

AWSはどちらかというとオープンソースとは縁の薄い企業と思われているが、それが変わりそうな兆しもある。この、Amazonのクラウドコンピューティング部門は今日(米国時間1/24)、Neo-AIのローンチを発表したがそれは、Apache Software Licensetheによるオープンソースのプロジェクトだ。この新しいツールは、同社が機械学習サービスSageMaker Neoのために開発して使っている技術の一部を、オープンソースのエコシステムに持参した(お返しした)ものだ。

その主な目的は、機械学習のモデルを複数のプラットホームで使うために行なう最適化を、もっと容易にすることだ。そしてAWSの文脈では、その複数のプラットホームとは多くの場合、これらのモデルをエッジで動かすマシンのことだ。

今日の発表声明でAWSのSukwon KimとVin Sharmaがこう書いている: “通常、機械学習のモデルを複数のハードウェアプラットホームのために最適化することは、プラットホームのハードウェアやソフトウェアの構成に合わせて手作業でモデルを調整しなければならないから難しい。とくに難しいのが、エッジデバイスの場合だ。コンピューターのパワーやストレージが限られていることが多いからだ”。

Neo-AIは、TensorFlowやMXNet、PyTorch、ONNX、XGBoostなどのモデルを最適化できる。AWSによると、Neo-AIがこれらのモデルのスピードを、精度の損失なく最初の倍ぐらいに上げてしまうことも多い。ハードウェアに関しては、IntelとARMとNvidiaのチップをサポートし、Xilinx、Cadence、そしてQualcommにも近く対応する。Nvidiaを除きこれらの企業のすべてが、このプロジェクトに寄与貢献している。

IntelのArtificial Intelligence Products GroupのトップNaveen Raoはこう語る: “AIが価値をもたらすためには、ディープラーニングのモデルがデータセンターでもクラウドでも、そしてエッジのデバイスでも、等しく容易にデプロイできなければならない。IntelがNeo-AIに寄与貢献することによって、nGraphで始めたイニシアチブを拡張できたことは、きわめて喜ばしい。Neoを使えば、デバイスのメーカーとシステムのベンダーが、オールIntelのコンピュートプラットホーム上の、ほとんどどんなフレームワークで開発されたモデルでもパフォーマンスをアップできる”。

このツールはモデルの最適化に加え、それらを新しいフォーマットに変換して、モデルが実際に実行されるデバイス上の互換性と、ローカルなランタイムの問題を防ぐ。

AWSによると、Neo-AIコンパイラーの開発の一部はワシントン大学のTVMTreeliteのプロジェクトで始まった。“本日、AWSのコードをNeo-AIプロジェクトとしてオープンソースにお返しすることにより、だれもがプロダクション級のNeoコンパイラーでイノベーションを追究できる”、とAWSは言っている。AWSはオープンソースのプロジェクトを自分のクラウドサービスに利用するだけ、という世評もあったが、今度からはお返しもするようになったのだから、めでたい。

Amazonのオープンソースへの取り組みとしては、同社のFirecrackerハイパーバイザーを挙げておくべきだ。これは今ではOpenStack FoundationのKata Containersプロジェクトをサポートしている。そのFirecrackerもオープンソースだから、いずれOpenStack Foundationに寄贈されたとしても、意外ではない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSがモバイルのイントラネットに容易にアクセスできるサービスWorkLinkをローンチ

会社がVPNやモバイルデバイスの管理サービスを使っているときには、イントラネットや社内のWebアプリケーションへのアクセスが、とても面倒なことになる。そこでAWSは今日(米国時間1/23)、Amazon WorkLinkという新しいプロダクトをローンチした。そのアクセスがずっと容易になる、と約束している。

AWSが完全な管理を提供するサービスWorkLinkは、ユーザー一人あたり月額5ドルで、社員に内部的サイトへのワンクリックアクセスを提供する。そのアクセスはITアドミンがコントロールでき、サイトはAWS上になくてもよい。

WorkLinkをスマートフォンにインストールしたら、社員は自分の好きなブラウザーを使って社内のWebサイトにアクセスできる。そのほかのソリューションは、あまり出来の良くないプロプライエタリなブラウザーの使用を強制されるものが多い。WorkLinkは仕事を開始し、目的サイトを安全にリクエストして…そしてここが賢いところだが…WorkLinkの安全なコンテナがサイトを対話的なベクターグラフィックに換えてスマートフォンへ送り返す。スマートフォン上には何も保存されずキャッシュもされない。またデバイス上の個人のアクティビティをWorkLinkが知ることもない。会社のデータも残らないから、スマートフォンをなくしたり盗まれたりしても、それらをリモートで消す必要もない。

ITはVPNを使ってAWSのVirtual Private Cloudからオンプレミスのサーバーに接続したり、またはAWSのDirect Connectを使ってVPNをバイパスすることもできる。このサービスは、OktaやPing IdentityなどSAML 2.0対応のアイデンティティサービスと一緒に使える(今企業で使われているアイデンティティサービスのほとんどがSAML 2.0だ)。完全なマネージドサービスなので、スケーリングやアップデートはバックグラウンドで行われる。

AWSの生産性アプリケーション担当VP Peter Hillはこう語る: “社員たちが内部的なコンテンツに容易かつ安全にアクセスできない、と不満を述べる顧客がとても多い。つまり彼らの社員は、時間を浪費したり、彼らの生産性を高めるコンテンツへのアクセスを最初からあきらめたりしている。AmazonのWorkLinkを使えば、会社のファイヤーウォールの外にいる人たちでもそんなコンテンツを利用でき、生産性を高めることができる。しかもそれはITの管理者やセキュリティのチームにとって使いやすいし、また社員たちも進んで使いたくなるだろう”。

WorkLinkはAndroidとiOSで使える‘予定’だが、現状はiOS(12より上)のみだ。しかもブラウザーはSafariのみで、数週間後にChromeがサポートされる。そして供用地域はヨーロッパと北アメリカのみで、その他の地域は今年の後半になる。

今のところ、クラウドでAWSの宿敵であるGoogleとMicrosoftには、WorkLink相当のサービスがない。GoogleはVPNに代わるものとしてCloud Identity-Aware Proxyを、BeyondCorpセキュリティ事業の一環として提供しているが、それはかなり目的が違う。一方Microsoftは、もっと従来的なモバイルデバイス管理ソリューションを提供している

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSがBackupをローンチ、完全な管理を伴うバックアップサービスだ

AmazonのクラウドコンピューティングサービスAWSが今日(米国時間1/16)、AWSのサービスからはもちろんオンプレミスのアプリケーションからも容易にデータをバックアップできるツールBackupをローンチした。それは今すでにAWSのユーザーなら誰もが利用でき、最初はバックアップのポリシーをセットアップする。それらはたとえば、Amazon EBSのボリュームやRDSデータベース、DynamoDBのテーブル、EFSファイルシステム、AWS Storage Gatewayのボリュームなどのためのポリシーだ。これら以外のそのほかのサービスも今後サポートされる。オンプレミスのデータをバックアップするためには、AWS Storage Gatewayを使用する。

このサービスによりユーザーは、さまざまなバックアップポリシーやリテンションポリシーを定義できる。たとえば、(EFSなどの)バックアップをコールドストレージに移せるようにするのか、一定の時間後に完全に削除するのか、など。デフォルトでは、データはAmazon S3のバケットに保存される。

サポートされているサービスの多くは、EFSファイルシステムを除き、すでにスナップショットを作る機能がある。基本的にBackupのやることは、その工程の自動化であり、またそのためのルールを設けることだ。というわけでBackupの利用料金は、スナップショット機能の使用料と同じだ(ファイルシステムのバックアップのみGB単位の課金となる)。なお、EFSファイルシステムや、DynamoDBのバックアップからのデータのリストアも、GB単位の課金だ。

現在、BackupはAWSのひとつのリージョンに限定されているが、同社によると年内には複数のリージョンにまたがるバックアップもできるようにする。

AWSでストレージとオートメーションと管理サービスを担当しているVP Bill Vassはこう言う: “クラウドは今や、どんな規模の企業でもデフォルトだから、二つの異なるタイプのビルダーを惹きつけている。ひとつは“いじくり屋”(tinkerers)で、AWSのサービスの全体をいじくり微調整して求めるアーキテクチャを実現する。もうひとつは、やはりAWSの機能性の幅広さと深さに惹かれるのだが、サービスの粒度の一部を犠牲にして、より高い抽象化層でスタートする。それによりビルドがもっと速くなることすらある。AWSのBackupは、後者のタイプのビルダーが対象であり、かねてから彼らは、個々のサービスごとにバックアップをするのではなく、一箇所でバックアップしたい、という要望を寄せていた”。

AWS BackupのアーリーアドプターはState Street Corporation, Smile Brands, そしてRackspaceだが、アドミンの仕事を楽にしてくれるから、ユーザーはとても多くなるだろう。しかしAWSにはバックアップやストレージ関連のパートナーがかなりいるから、AWSのこの市場への進出を喜ばない人たちもいるはずだ。彼らには、AWSのBackupよりも幅広い機能性(クロスリージョンやオフサイトバックアップなど)があることが多いのだから。

画像クレジット: TechCrunch

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSがサーバーレスLambdaの機能を多様化、複数のプログラミング言語をサポート

AWSは2015年にLambdaをローンチし、それによってサーバーレスコンピューティングが広く利用されるようになった。ユーザーはイベントトリガーとなるコードを書き、それを動かすための計算処理やメモリ、ストレージなどの手配はすべてAWSが担当する。今日(米国時間11/29)ラスベガスで行われたAWS re:Inventで同社は、Lambdaをもっとデベロッパーフレンドリーにするいくつかの新しい機能を発表した。サーバーレスは複雑性を減らしてくれるが、でもそれが成熟するためにはより高度なツールが必要なのだ。

デベロッパーは、コードは書くけどその実行に必要なサーバーの心配はしない。だからサーバーレスと呼ばれる。すべての面倒をクラウドベンダーが見てくれて、イベントの実行に必要なリソースの手配をすべて行なう。デベロッパーは、インフラストラクチャまわりのコードを書く必要がなくなり、アプリケーションが仕事をするために必要なコードだけを書けばよい。

AWSのやり方は、とにかく最初に何かをベースサービスとしてリリースし、顧客の利用とともに要求が増えてくると、サービスの機能を増やしていく。AmazonのCTO Werner Vogelsが木曜日(米国時間11/29)のキーノートで指摘したように、デベロッパーたちはツールについてよく議論をするが、それを聞いていると、誰もが自分の仕事のためにほしいツールのアイデアを持っていることが分かる。

そこで最初に同社は言語に着目して、新しい言語のサポートを導入した。たとえばRubyを使っているデベロッパーは、これからはRuby Support for AWS Lambdaを使って、“LambdaのファンクションをRubyに合ったコードで書き、それらをAWSの上で実行できる。Ruby用のSDKはLambdaの実行環境にデフォルトで含まれている”、とAWSのChris Munnsが、この新しい言語サポートを紹介するブログ記事で述べている。

C++派の人たちのためには、C++ Lambda Runtimeが発表された。また、これら以外の言語のためには、Lambda Runtime APIが新たに用意された。AWSのDanilo Pocciaはブログ記事でこれを、“ファンクションの開発に、さまざまなプログラミング言語やその特定のバージョンを使えるための、シンプルなインタフェイスだ”、と説明している。

またIDEに関しては、PyCharm, IntelliJ, そしてVisual StudioのサポートがLambdaに導入された(現状はプレビュー)。

AWSは、言語とIDEのサポートだけで満足していない。たしかにLambdaは(一般的にサーバーレスは)デベロッパーのためにあるレベルまでの複雑性を取り去ってくれるが、でもサーバーレスのアプリケーションは簡単なイベントトリガーだけではない。より高度なサーバーレスアプリケーションでは、システムレベルの要素を持ち込んだり、複数の部位をまとめたりしなければならない。Vogelは今日のキーノートで、このことを指摘した。

そこで複雑高度なサーバーレスアプリケーションのためにAWSが導入したのが、Lambda Layersだ。それは、彼らの説明によると、“複数のファンクションが共有するコードとデータを管理する方法”だ。それは複数のファンクションが使用するカスタムコードでもよいし、ビジネスロジックを単純化するためのコードを共有するような場合でもよい。

Lambdaの成熟と共に、デベロッパーの要求もうるさくなる。今回のさまざまな発表は、それらのニーズに応える努力の一環だ。

more AWS re:Invent 2018 coverage

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

ユーザーが自分のクラウドの正しい使い方をチェックできるAWS Well Architectedツール

2015年からAWSは、システム設計のチームを顧客元へ派遣して、彼らのAWSの使い方の正否をチェックしてきた。今日(米国時間11/29)同社が発表したツールWell Architectedを使うと、顧客はそのチェックを、自動化された方法で自分でできるようになり、人間コンサルタントの助力が要らなくなる。

AmazonのCTO Werner Vogelsがラスベガスで行われたAWS re:Inventのキーノートで述べたように、同社社内の人間チームが何千もの顧客のニーズに対応して、彼らのAWSベストプラクティスをチェックすることは困難である。資格を与えた複数のパートナーの起用も試みたが、それでも需要の大きさには対応できなかった。

そこで、いかにもAWS的なやり方として同社は、顧客が自分で、オペレーションやセキュリティ、信頼性、費用の最適化、性能効率などを測定できるサービスを作ることにした。顧客はこのツールを自分が使っているAWSサービスに対して動かし、上記5つのチェック項目に関する完全な測定レポートを得ることができる。

AWSのチーフエヴァンジェリストJeff Barが、このサービスを紹介するブログ記事でこう言っている: “これは、あなたがクラウドを確実に正しく、そして上手に使うためのツールだ”。

人間がユーザーのシステムを分析するのではなく、ユーザーが一連の質問に答えていくと、その答に基づいてレポートが生成される。そのPDFのレポートには、ユーザーの現状に応じた勧奨事項がすべて書かれている。

画像提供: AWS

人間コンサルタントとの会話に比べるときめ細かさに欠けるのでは、という疑念もあるが、これをもっと詳細な問題解決に向けてのスタートラインと考えてもよい。サービスは無料だから、ユーザーが費用的に失うものはないはずだ。

more AWS re:Invent 2018 coverage

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

推論過程をGPUで加速するAmazon Elastic Inferenceはディープラーニングのコストを75%削減する

Amazon Web Servicesが今日、Amazon EC2のどんなインスタンスでもGPUによる推論の加速ができるサービスAmazon Elastic Inferenceを発表した。これにより、ディープラーニングのコストが最大75%削減できるという。

AWSのCEO Andy Jassyは、今朝のAWS re:Inventのステージでこう述べた: “従来のP3インスタンス(GPU常備のインスタンス)では通常、GPUの利用率がせいぜい10%から30%ぐらいで、エラスティックな推論用としては無駄が多い。それだけの費用やGPUを、無駄に使うべきではない。Amazon Elastic Inferenceでは、もっと費用効率の良い方法で推論エンジンを動かせるから、きわめて画期的なサービスだ”。

Amazon Elastic Inferenceは、モデルの作成/学習ツールAmazon SageMakerのノートブックインスタンスとエンドポイント用にも利用でき、“内蔵アルゴリズムとディープラーニングの環境を加速できる”、と同社はブログ記事で言っている。機械学習のフレームワークは、TensorFlow, Apache MXNet, そしてONNXをサポートしている。

[顧客の皆様には、仕事の性質に合った正しいツールを使っていただきたい。このたび発表するAmazon Elastic Inferenceを使うと、エラスティックな(伸縮性のある)GPUサポートを加えて、どんなEC2インスタンスの上でもスケーラブルな推論ができ、大幅な経費節約が可能だ。]

三つのサイズが提供されている:
(混合精度, mixed-precision, FP16とFP32の併用使い分け)

  • eia1.medium: 8 TeraFLOPsの混合精度パフォーマンス
  • eia1.large: 16 TeraFLOPsの混合精度パフォーマンス
  • eia1.xlarge: 32 TeraFLOPsの混合精度パフォーマンス

この新しいサービスを詳しく知りたい方は、こちらへ

more AWS re:Invent 2018 coverage

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWS Transit Gatewayは多種多様なリソースを単一のネットワークトポロジーの下に収めてアクセスと管理を容易化

AWSのデベロッパーカンファレンスre:Inventで今夜(米国時間11/26)、AWS Transit Gatewayと呼ばれるツールが発表された。それはユーザーがAWSの中にネットワークトポロジーを構築して複数のアカウントのリソース共有し、オンプレミスとクラウドのリソースを単一のネットワークトポロジーの中へ一元化する。

Amazonにはすでに、Amazon Virtual Private Cloud(VPC)と呼ばれる人気のプロダクトがある。顧客はこれを使って、自分のアプリケーションのプライベートなインスタンスを作れる。一方Transit Gatewayでは、複数のVPCs間の接続を構築できる。それはこれまで、相当面倒な作業だった。

AWSのグローバルインフラストラクチャとカスタマーサポート担当VP Peter DeSantisの説明によると、ユーザーはAWS Transit Gatewayにより中央集権的に管理されるゲートウェイに接続でき、その単一のコントロール集合を駆使して、ネットワークを容易にそして迅速に成長させられる。

図表提供: AWS

DeSantisによると、このツールはAWSとオンプレミスの両ネットワークを横断する能力をユーザーに与える。“ゲートウェイはイノベーションの一つの方法であり、それにより顧客は、安全で管理しやすい単一のネットワーキングをオンプレミスとAWSクラウドの両方にまたがって持つことになる”、と彼は説明する。

さまざまなリソースが標準的な種類のネットワークトポロジー上にあるかぎり、それらのリソースがどこにあろうとも、AWS Transit Gatewayによりそれらに一つのネットワークとして接続できる。“AWS Transit Gatewayを使ってハブ-アンド-スポーク型(車輪の中心とそこから放射状に張り出されたスポーク)のネットワークを構築できる。そこには、既存のVPCsやデータセンター、リモートオフィスなど何でも接続できて、そのネットワークルーティングやセキュリティを完全にコントロールできる。そのVPCsやActive Directories、共有サービス、そのほかのリソースなどが、複数のAWSアカウントに広がっていてもよい”。AmazonのJeff Barrが、この機能を発表するブログ記事にこう書いている。

長年、AWSといえばクラウドであり、ユーザーのクラウドリソースを管理するサービスを提供してきた。それはAWSのようなクラウドだけの企業にとっては十分だが、顧客は多種多様であり、インフラストラクチャやソフトウェアがオンプレミスやクラウドなど、いろんなところに散在している企業も少なくない。それらを、仮想的に単一のネットワークトポロジーとして扱えるようにするのが、AWS Transit Gatewayだ。

more AWS re:Invent 2018 coverage

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSのGlobal Acceleratorはアプリケーショントラフィックのグローバルネットワーク上の最適ルートを見つける

AWSの顧客は、さまざまな理由で複数のゾーンでアプリケーションを動かさなければならない場合が多い。理由としては、パフォーマンスの要求もあるだろうし、各国の規制の問題や、フェイルオーバーの管理もあるだろう。その理由が何であれ、AWS今夜(米国時間11/26)、顧客が複数のリージョンにまたがってトラフィックを容易にルートできるためのツールGlobal Acceleratorを発表した。

AWSのグローバルインフラストラクチャとカスタマーサポート担当VP Peter DeSantisが月曜の夜AWS Re:Inventで説明したところによると、AWSの顧客のトラフィックはすでにAWSの大きなネットワーク上を流れており、顧客はAWSのDirect Connectを使ってアプリケーションのパフォーマンスを一定に保ち、AWSの複数のリージョン間で移動する場合もネットワークの変動がないようにしている。しかし彼によると、これまで欠けていたのは、AWSのグローバルなネットワークを使って彼らのアプリケーションを最適化する方法だ。

DeSantisはre:Inventの聴衆に向かってこう述べた: “今夜、AWS Global Acceleratorをみなさまに発表できることを嬉しく思っております。AWS Global Acceleratorによりみなさまは、AWSのグローバルなネットワークを利用してアプリケーションのパフォーマンスと可用性を容易に向上できます”。

説明図提供: AWS

DeSantisは曰く: “;みなさまの顧客のトラフィックはエンドユーザーから最寄りのAWSエッジロケーションへルートされ、そこから、渋滞のない、冗長性のある、可用性の高いAWSグローバルネットワークを渡っていきます。そのときAWS Global Acceleratorはパフォーマンスを上げるだけでなく、エラー隔離機能によりネットワークの健康状態やみなさまのアプリケーションの構成の異変に直ちに反応します”。

そのときネットワークのアドミニストレーターは、健康状態や地理的要件などのポリシーに基づいてトラフィックをルートでき、トラフィックはそれらのポリシーに基づいて行き先のゾーンへと自動的に移動していく。

AWSの計画では、課金は顧客が作るアクセラレータの数に基づいて行われる。“アクセラレータはAWSのグローバルネットワーク上でトラフィックを最適のエンドポイントへと差し向けるために作るリソースだ。通常は一つのアプリケーションにつき一つのアクセラレータをセットアップするが、複雑なアプリケーションが複数のアクセラレータを必要とする場合もある”、とAWSのShaun Rayが、この新しい機能を発表するブログ記事に書いている。

AWS Global Acceleratorは今日から、アメリカとヨーロッパとアジアのいくつかのリージョンで利用できる。

画像クレジット: Ron Miller

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Amazon Comprehendでは機械学習の技術とは無縁なデベロッパーでも専門用語で自然言語処理モデルを訓練できる

昨年Amazonは、自然言語処理のツールComprehendを発表した。それは情報のコーパスから、よく使われている語や語句を取り出し、ドキュメントを分類する。今日Amazonは同社のデベロッパーカンファレンスRe:inventに一週間先駆けて、Comprehendの機能向上を発表した。それにより機械学習の専門知識のないデベロッパーでも、専門用語や語句のリストを作るだけで機械学習のモデルを構築できる。

その機能アップを発表するブログ記事で、AmazonのディープラーニングとAIのゼネラルマネージャーMatt Woodがこう書いている: “本日Comprehendに新しいカスタム化機能を導入することを嬉しく思う。これによってデベロッパーは、Comprehendを拡張して自然言語で書かれている用語を見つけ、チームや企業や業界にとって専門的なテキストを分類できる”。

重要なのは、すべての複雑な処理をAmazonが面倒見るので、機械学習や自然言語処理の素養のないデベロッパーでも言葉のリストをシステムに与えるだけで、テキストからそれらの語を検出/取り出しできるようになることだ。Woodは書いている: “カスタマイズされた機械学習のモデルを構築、訓練、そしてホストする重労働はすべてComprehendが行い、これらのモデルをプライベートなAPIでデベロッパーが利用できるようにする”。

これには、二つの部分がある。まず、デベロッパーは専門用語などのリストを作る。それは、たとえば法律事務所なら法律用語、自動車会社なら部品番号のリストだったりするだろう。デベロッパーがすることは、これらの用語のリストを公開するだけだ。Comprehendがカスタマイズされた言葉を見つけることを学習し、そのリストに基づくプライベートでカスタマイズされたモデルを作る。

第二の部分は、分類のカスタマイズだ。言葉のリストを作ったら、次は、それらの用語が現れる論理(ロジック)のリストを作る。それについてWoodは、こう書いている:

“言葉の用例がわずか50件でも、Comprehendはカスタムの分類モデルを自動的に訓練し、それを使ってユーザーのドキュメントを各カテゴリーに分類する。たとえばカスタマーサポートのメールを、担当部門ごとにグループ化したり、ソーシャルメディアのポストを製品別に分類、あるいはアナリストの報告書を事業部別に分類したりできるだろう”。

これらの雑多で大量のドキュメントは、カテゴリー分けして初めて役に立つし、適切な担当者にそれを渡したり、あるいはアプリケーションがプログラムの一環として利用したりできるようになる。

Comprehendはユーザーに、カスタマイズされた機械学習のモデルを作る方法を、上述のようなごく単純な方法として提供し、楽屋裏の細部は自分でやる。一般的に言っても、クラウド企業は複雑難解なものを単純化して、専門的な知識や技能のないデベロッパーでも一連のサービスを利用できるようにする。Comprehendの場合は、機械学習の知識のない者がカスタマイズされたモデルを作れる方法を提供する。

Comprehendのこの新しい機能は、今日(米国時間11/19)から利用できる。

〔参考記事
Amazon Comprehend日本語ドキュメンテーション(1)
Amazon Comprehend日本語ドキュメンテーション(2)
Amazon Comprehend用例解説(1)
Amazon Comprehend用例解説(2)
「amazon comprehend 日本語」でググると、さまざまな日本語ドキュメンテーションが出てきます。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

VMwareがその顧客元実装上にAWSのRelational Database Serviceを導入

ちょっと意外なニュースだ。Amazonのクラウドコンピューティング部門であるAWSが、今日(米国時間8/27)の発表によると、同社のRelational Database Service(RDS)をVMwareに持ち込む。それはAWS上のVMware Cloudと、企業が自分のデータセンターでプライベートに動かすVMwareの両方だ。

AWSのコンペティターの一部は、かなり前から、こういうハイブリッドなクラウドのデプロイにも力を入れてきたが、AWSはそれほどでもなかった。でも今や、それが変わろうとしている。それはたぶん、Microsoftなどの競合他社がこの分野で好調だからだろう。

AWSのCEO Andy Jassyはこう述べている: “データベースは、その管理にも運用にも、泥沼のように面倒で厄介な側面がある。だからこそ何十万もの顧客がAmazon RDSを信頼して、大規模なデータベースの管理を任せているのだ。この、オペレーションの現場で鍛えられた同じサービスを、オンプレミスやハイブリッド環境の顧客にご提供していけるのは、とてもすばらしいことだ。それによって、エンタープライズのデータベース管理が容易になるだけでなく、データベースをクラウドに移行する作業も、より単純になる”。

Amazon RDSがVMwareに来たことによって、エンタープライズは、AWSの技術を利用してMicrosoft SQL ServerやOracle, PostgreSQL, MySQL, MariaDBなどのデータベースを利用できる。たとえば、どこでデータをホストするにしてもデータベースのセットアップと管理が楽になる。…そして将来的には、AWSへの移行も容易になるだろう。

この新しいサービスは目下非公開プレビューなので、その詳細や料金などはまだ分からないが、ユーザー体験はクラウドの場合とほぼ同じだろうし、VMware上のRDSもアップデートやパッチを自動的に行なうことになるのだろう。

今日の発表は、AWS上のVMware Cloudのローンチから約2年後になる。それは今日の発表の真逆で、VMwareがAWSに来る、というものだった。VMwareのデプロイを動かしているエンタープライズは、それをそのまま、AWSへ移せるのだ。

関連記事: VMwareがついにクラウドサービスを提供、しかもAWSとのパートナーシップのもとで

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Amazon、開発者向けAIカメラ “DeepLens” を249ドルで販売開始

昨年11月のre:Inventカンファレンスで、Amazon AWSはDeepLensを発表した。これは開発者向けに作られたもので、視覚に特化した機会学習モデルの開発とプロトタイピングに利用される。同社は数ヶ月前にDeepLensの予約を開始し、今デベロッパーに向けて出荷が始まった。

今日の発売に先駆け、私はシアトルのワークショップでDeepLensのシニアプロダクトマネージャー、Jyothi Nookula、および AmazonのAI担当VP、Swami Sivasubramaniaとともにハードウェアとソフトウェアサービスを体験する機会を得た。

DeepLensは実質的にはUbuntu-/Intel Atomベースのカメラ付き小型コンピューターで、単体でビジュアル機械学習を実行できる能力をもっている。DeepLensは総合性能は約106 GFLPSだ。

ハードウェアは一般的な入出力ポート(Micro HDMI、USB 2.0、オーディオ出力など)を備え、カメラが裏庭でクマを見つけたら警告を送るおもちゃアプリから、工場のベルトコンベアーを監視する産業アプリまでさまざまなアプリのプロトタイプを作ることができる。4 Mピクセルのカメラは何か注目を浴びるものではないがほとんどの用途に十分適している。当然ながらDeepLensは他のAWSサービスと深く統合されている。AWSのIoTサービスであるGreengrassはDeepLensにモデルを配信する際に利用し、Amazonの機械学習モデル構築用最新ツールであるSageMakerとも連携する。

こうした連携は、非常に簡単にカメラを使い始められるのにも役立っている。あらかじめ用意されているモデルを使えば、10分足らずでDeepLensを設定しモデルを組み込んで利用できる。プロジェクトテンプレートの中には、20種類の物体を識別する別体検出モデルや、カメラ画像をゴッホ風に変換するスタイル変換モデルや顔認識モデル、猫と犬を区別するモデル、約30種類の動作(ギターを弾く、など)を認識できるモデルなどがある。DeepLensチームは、頭部の姿勢を追跡するモデルも開発中だ。そうそう、ホットドッグ検出モードもある。

それだけではない。開発チームはワークショップの中で、機械学習の経験がまったくないデベロッパーでも既存のテンプレートを簡単に拡張できることを強調していた。ひとつには、DeepLensプロジェクトが2つの部分からなっているためだろう。モデルおよびモデルの出力に基づいてモデルのインスタンスをアクションを実行するLambda機能だ。AWSは、ベースにあるインフラストラクチャーを管理することなくモデルを簡単に作るためのツールとしてSageMakerを提供している。

DeepLensのハードウェアは実質的に小さなコンピューターなので、それ自身でさまざまな開発が可能だが、おそらくもっと強力なマシンで開発してからAWSコンソールを使ってDeepLensに転送する方がいいだろう。それでもDeepLensを低性能デスクトップマシンとして使いたいという人のために、Ubuntu 16.04がプレインストールされている。

機械学習のフレームワークに慣れているデベロッパーなら、DeepLensを使うとCaffe、TensorFlow、MxNetなどほぼすべての人気ツールから簡単にモデルをインポートできる。またAWSチームはMXNetモデルをDeepLensデバイスでより効率よく動作するための最適化ツールも作ったことも報告しておく。

ではなぜAWSはDeepLensを開発したのだろうか? 「DeepLensカメラを作った理由は、われわれが自身に問いかけたある単純な疑問にあった:機械学習もデベロッパー全員の手に届けるにはどうすればよいか?」とSivasubramanianは言う。「ブレーンストーミングを重ねた結果、最も有望な発見は、デベロッパーは実際にデバイスに手を触れて開発するのが大好きだというアイデアだった」。しかしなぜAWSはパートナーと協力するのではなく独自にハードウェアを作ったのか?「われわれには具体的な顧客体験のアイデアがあり、すべての体験が本当に簡単であることを確かめたかったからだ」と彼は言った。「このハードウェアを買って、Amazonからこのツールをダウンロードして、などと言っていると環境が揃うの2~3日かかってしまう。それでは、ディープラーニングを学んで何か楽しいものを作ろうとワクワクしている人にとっては長すぎる」

そういうわけで、、これから機械学習を使ったプロジェクトを始めたい人は、DeepLensをAmazonから購入できる。249ドルは安くはないが、すでにAWSを使っていて——しかもすでにLambdaも使っていれば——おそらく簡単に機械学習アプリケーションを作り始めることができるだろう。

[原文へ]

(翻訳:Nob Takahashi / facebook

AWSのデータベースサービスAuroraにアンドゥ機能が誕生、72時間の遡及可能

AWSの‘マネージドMySQL/PostgreSQL’データベースサービスに、アンドゥ機能がつく。今日の同社の発表によると、そのAurora Backtrack機能により、ユーザーは“時間を逆行できる”。今それはMySQLのみだが、この機能を有効にするとそれ以降新たに作られるデータベースクラスターとバックアップからリストアされたクラスターに対し、アンドゥができるようになる。それまであったデータベースは、ノーだ。

この機能を有効にすると、AWSは最大72時間ぶんのトランザクションのログを取る。本番のデータベースに不正なテーブルを入れた、などの間違いに気づいたら、アプリケーションをポーズして、どこまで戻りたいか、時間(時刻)を指定する。するとAuroraはデータベースもポーズして、開いているすべての接続を閉じ、まだコミットしてないものをすべて落としてから、指定された時点までロールバックする。

もちろん、トランザクションの逆行はAWSが初めてではない。MySQLも含め、多くのデータベースシステムが、すでに何らかの形で実装している。ただしそれらの多くは、今日AWSが発表したものに比べると範囲が狭い。

AWSのチーフエヴァンジェリスト(Chief Evangelist) Jeff Barrが今日の発表で言っているが、それは災害復旧だけが目的ではない。彼はこう書いている: “あなたも、このクールな新しい機能の、クリエイティブで奇抜な使い方を、きっと思いつくだろう。たとえば、本番データベースでいろんなテストをして、そのテストの痕跡をすべて掃除することもできる。復旧の指示は、APIまたはCLI(コマンドライン)からできるから、この機能を既存のテストフレームワークに統合するのも容易だ”。

Aurora Backtrackは今、すべてのデベロッパーが使える。料金は、アメリカリージョンではレコードの書き換え100万文字につき約0.012ドルだ。ヨーロッパとアジアでは、やや高くなる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSのDynamoDBが継続的自動バックアップと事故時の即時リカバリを提供

クラウドコンピューティングはいろいろ便利だが、データの扱いもクラウドのベンダーがやってくれるのがありがたい。でもそれは、ソフトウェアをアップデートしてくれるとか、ハードウェアのスケールアップ/ダウンを勝手にやってくれる、ぐらいのことだった。しかし今日(米国時間4/4)AWSはそれを一歩進めて、Amazon DynamoDB Continuous BackupsおよびPoint-In-Time Recovery(PITR)〔継続的自動化バックアップと即時リカバリ〕なるものを発表した

この新しいサービスでは、ユーザーがバックアップツールを有効にしておくと、バックアップが自動的に行われる。あとのことはすべてAmazonが面倒を見て、ユーザーのDynamoDBデータベースにあるすべてのデータを継続的にバックアップする。

しかもそれだけではなく、バックアップシステムは記録もつける。つまり、そのおかげで、過去35日以内ならデータの“巻き戻し”ができて、その粒度は秒単位だ。しかもそのツールにはユーザーがAWS Management Consoleからアクセスでき、AWS Command Line Interface(CLI)でAPIを呼び出せる。

スクリーンショット提供: Amazon

この新しい機能を発表するブログ記事でAmazonのRandall Huntが書いている: “この機能を作ったのは、事故的な上書きや削除からユーザーとデータを守るためだ。デベロッパーがステージングではなくプロダクションに対してスクリプトを動かしたとか、どこかのファットフィンガー(fat-finger, 指が太すぎるやつ)が間違ってDeleteItemボタンを押してしまったときには、PITRが助ける。また、ユーザーにとって予想外の事態にも対応できる”。

35日のリミットが気になる人は、通常の定期的なオンデマンドのバックアップならいくらでも長期保存できることを、おぼえておこう。

AmazonのCTO Werner Vogelsが、今日サンフランシスコで行われたAWS Summitでこの新しいサービスを紹介した。そして、どれだけ大量のデータがあっても平気だ、と言った。つまりこれらの新しいサービスは、データ量がテラバイト級でも使える。“これはAWSの本当に強力な仕組みなんだ”、とVogelsは自画自賛した。

この新しいサービスは今日からいくつかのリージョンで可利用になる。それらがどことどこか知りたい人は、このページを見てみよう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSがパリに新リージョンを開設、フランスのデータプライバシー法への準拠が容易に

Amazon Web ServicesがEUの顧客のために、フランスのパリに新しいリージョンを立ち上げた。これはドイツ(フランクフルト)、アイルランド、イギリス(ロンドン)に次ぐヨーロッパ第四のリージョンだ。パリ・リージョンのアドバンテージは、フランスのテクノロジー企業にとってデータプライバシーの規制に準拠しやすいことだ。

このリージョンにはアベイラビリティーゾーンが三つあり、それぞれが自分のインフラストラクチャを持って地理的に分かれている。電力などのインフラを独自化しているのは、災害時などにサービスが全滅しないためだ。パリ・リージョンではさらに、顧客がフランスに保存したユーザーデータが、顧客自身が移動させないかぎり、AWS自身の都合などでは移動されない。フランスのデータ独立法は厳しくて、テクノロジー企業はフランス国民からのデータを国内に保存しなければならない。AWSはすでにフランスに三つのエッジネットワークロケーションを持ち、顧客がそこからWebサイトなどのサービスをエンドユーザーに届けられるようにしている。

声明文の中でAWSのCEO Andy Jassyが言っている: “すでに数万ものフランスの顧客がフランスの外のリージョンからAWSを使っているが、彼らはフランスの国内にリージョンができることを熱烈に要望していた。それはレイテンシーに敏感なワークロードの多くを容易に運用できるためであり、またフランスの国土の上に在住すべきデータをすべてそこに格納できるためだ”。

AWSのすべてのリージョンに共通する同一のセキュリティ準拠規格もあるほか、AWSのインフラストラクチャは、さまざまな国のプライバシー関連法を守りつつ大西洋にまたがって情報交換を行うためのフレームワークEU-U.S. Privacy Shieldを認定されている。またEUが2018年5月25日に実装する予定のGeneral Data Protection Regulation(GDPR)にも、準拠している。

AWS EU(Paris)と呼ばれるパリのリージョンの開設により、AWSのリージョンは全世界で18になり、アベイラビリティーゾーンは49になる。AWSのフランスの顧客には、Canal+, Decathlon, Les Echoes, Schneider Electric, Societe Generaleなどがいる。

〔参考記事: AWSのリージョンとアベイラビリティーゾーン

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

AWSのAppSyncでアプリケーションのオフライン利用が可能に

【抄訳】
Webホスティングサービスの王者の勝利を誇示するような大集会が、今年もラスベガスで行われている。そのAmazon Web Servicesのデベロッパーカンファレンスre:Inventでは今日(米国時間11/28)、このサービスがホストしているアプリケーションをオフラインでも使える新しい機能、AppSyncが発表された。

今朝発表された同社のブログ記事が、この新しいサービスの概要を説明している。

その記事によると、AWS AppSyncは、完全に管理されたサーバーレスのGraphQLサービスで、デバイスがオフラインでもリアルタイムのデータクェリを可能にする。そして接続が可利用になればローカルデータをシンクする。

Amazon技術のエヴァンジェリストのようなTara Walkerの、少々分かりづらいブログ記事によると、GraphQLはデータクェリ言語で、リアルタイムのデータ取り出しとクェリの動的実行を行うサーバーサイドのランタイムだ。

クライアントアプリケーションを作るときにはGraphQLはアプリケーションレイヤで動き、スキーマを定義するためのタイプシステムを提供する、と上記のWalkerは言っている。

そしてこれらのスキーマが、データに対する操作の仕方とデータの構造をコントロールするスペックになる。GraphQLはまた、多くのプログラミング言語やライブラリがサポートしている宣言的プログラミングモデルで動作する(これもWalkerより)。

以上でよく理解できた方は、ぼくよりも優秀だ。でもなにしろ、Walkerは、AppSyncについてこのように書いているのだ。

デベロッパーはスキーマを作って、GraphQLで開発するAPIのタイプと能力を定義し、“Resolver”ファンクションに結びつける。スキーマは既存のデータソースに基づいていてもよいし、あるいはAppSyncがスキーマの定義に基づいて自動的にテーブルを作ることもできる。

デベロッパーは、バックエンドのデータソースに関する知識がなくても、GraphQLの機能を利用してデータの発見(データディスカバリ)ができる(これは便利だ)。

Walkerは、さらにこう説明している:

【後略】

[原文へ]
(翻訳:iwatani(a.k.a. hiwa