Quantcast
Channel: Amazon Web Services ブログ
Viewing all 446 articles
Browse latest View live

あたらしいAWSクイックスタート - Magento for E-Commerce

$
0
0

  

Magentoは、E-コマースサイト向けのオープンソースコンテンツマネージメントシステムとして、とても有名です。売り手と開発者にとって、そのオープンなアーキテクチャ、柔軟性、拡張性(数百のエクステンション)、そして、顧客ごとの固有のニーズにフィットするよう調整可能なバックエンドであることがよく知られています。

Magento Community Edition (Magento CE)、Magento Enterprise Edition (Magento EE)は、AWSのお客様にも人気があります。Anchor HostingElasteraTenzingRazorfishOptarosのようなパートナーを経由して、AWS上で起動されている実績があります。そのほか、AWS MarketplaceMagentoを検索すると20以上表示されます)を経由しても起動されています。また、そのほか、自分自身で立ち上げているユーザもいます。

本日、私たちは、新しい、「Magento クイックスタートデプロイメント」を公開しました。29ページからなるドキュメントは、Magento Community Editionのバージョン1.9.2が実行するAWSクラスターを構築する方法について記載しています。これは、ベストプラクティスを通じて、コスト見積方法、AWSコンポーネントの推奨されるセットの概要について順をおって説明しています。

 

クイックスタートで示されているAWS CloudFormationテンプレートを使用して、新規または既存のバーチャルプライベートクラウド(Amazon VPC)に、Magentoを起動させることができます。テンプレートは、(必要に応じて)VPC、必要とされるEC2インスタンス(自動的にスケールするWebサーバおよびSSH接続用のNATインスタンス)と一緒に、MySQLが動作するAmazon Relational Database Service(RDS)インスタンス、Elastic Load Balancingを作成します。あわせて、必要なIAMロールとセキュリティグループを作成し、トラフィックが上昇するときにEC2インスタンスが追加され、それがおさまるとインスタンスが削除される、Auto Scalingが設定されます。完成したシステムは次のようになります:

 

クイックスタートには、Magentoのサイトからダウンロード可能ないくつかのサンプルデータのポインタが含まれています!

 

Jeff; (翻訳:瀧澤与一 原文:New AWS Quick Start – Magento for E-Commerce)

 

 


週刊AWS - 2015年8月31日

$
0
0

毎週水曜日の18時から開催しているBlack Belt Tech Webinarに参加したことはありますか?プレゼンテーションの最後に質問コーナーを設けているのですが、時間の関係ですべてにお答えできないケースもあります。AWS Solutions Architectブログにていただいたご質問への回答を掲載しておりますので、疑問点があればぜひチェックしてみてください。

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 

8/31(月)
9/1(火)
9/2(水)
9/3(木)
9/4(金)
9/5(土)

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

このブログの最新情報はTwitterでお知らせしています。お気軽に@awscloud_jpをフォローください。
----
ソリューションアーキテクト 小林正人

【AWS発表】EC2 Spotインスタンスのリソース指向の入札機能

$
0
0
今年始めに、EC2 Spot フリートAPIを紹介しました。以前のポストで述べたように、このAPIによって、1回のリクエストでSpotフリートのインスタンス群を起動・管理することができます。フリートが必要とするキャパシティ、時間あたりの入札価格、インスタンスタイプを指定します。Spotフリートは最安値のEC2キャパシティを見つけ、そのキャパシティを維持するようにします。
 
本日、入札に重み付けを加えることによって、SpotフリートAPIをさらに強力にしました。この新機能は、インスタンスタイプとアベイラビリティゾーンを、皆さんのアプリケーションに最も適したように入札・起動することを可能にします。RequestSpotFleet APIを呼び出す際には、(インスタンス1台あたりの)入札価格を1つ指定します。これは簡潔に使うことができますが、簡単にするために望ましい機能を制限していることでもあります。例えば、最低488GiBのメモリを2台以上のR3(メモリ最適化)インスタンスで欲しい、または最低128vCPUを C3とC4(いずれもコンピュート最適化)インスタンスの組み合わせで欲しい、という場合があります。
 
新機能:リソース指向の入札
新機能のリソース指向入札モデルは、このような種類のSpotフリートリクエストを可能にします。フリート内の各インスタンスは、作成するフリートを最適サイズにするために影響するいくつかのリソースを「キャパシティユニット」として保持します。先ほどの例だと、何GiBのRAMもしくは何vCPUのリソースが必要か?ということになります。EBS最適化の帯域幅、計算能力、ネットワーク性能やその他アプリケーション固有の単位(おそらくより抽象的でしょう)も相当します。本日より、キャパシティユニットをSpotフリートのリクエストパラメータとして使え、キャパシティユニット全体に対する各インスタンスの割合も表示します。
 
その結果、各インスタンスタイプが実際に使えるかどうかを気にせずに、複数のインスタンスタイプのリソースを、場合によっては複数のアベイラビリティゾーンに跨って使うことができます。既に、各RequestSpotFleet リクエストには複数の 起動設定(launch specification)を指定でき、要求したインスタンスタイプごとにAMIを指定できます。各々の起動設定(launch specification)には、以下の様な値を指定できます:
 
WeightedCapacity - 指定したインスタンスタイプがフリート全体のキャパシティのどのくらいを占めるようにするかを指定します。SpotフリートがSpotインスタンスの入札を行う際に、ユニット毎の入札価格を積算します。例えば、 15.25GiBメモリの r3.largeインスタンスに較べて、30.5GiBメモリを搭載したr3.xlargeインスタンスに対して 2倍の費用払う、という入札が可能です。
 
SpotPrice - 特定のユニット単位の入札価格として指定し、インスタンスの入札価格より優先します。この値を使うことで、特定のインスタンスタイプ、アベイラビリティゾーンやサブネットを選択させやすくする(もしくは選択させにくくする)ような記述が可能です。
 
先ほどの例として紹介したメモリ重視の起動設定です:
Instance TypeInstance Weight
 r3.large 15.25
 r3.xlarge 30.5
 r3.2xlarge 61
 r3.4xlarge 122
 r3.8xlarge 244
 
488 (希望するフリートキャパシティをGiBで指定)のターゲットキャパシティと、そのキャパシティに支払いたい価格( GiB/時)を 入札価格として、RequestSpotFleetを実行したとします。その場合、r3.largeに比べr3.8xlargeは16倍高い価格を支払う、と宣言したことになります。
 
EC2はこの情報を元に、ユニットあたりのSpot価格が最安で利用可能なインスタンスを探し、最も経済的な組み合わせのフリートを構築します。以下の様に、単一のインスタンスタイプを使ったシンプルな構成が可能です:
 
  • 2 x r3.8xlarge
  • 4 x r3.4xlarge
  • 8 x r3.2xlarge
  • 16 x r3.xlarge
  • 32 x r3.large
 
以下の様に、複雑な混成構成になるかもしれません:
  • 1 x r3.8xlarge と 2 x r3.4xlarge
  • 2 x r3.4xlarge と 8 x r3.xlarge
  • 8 x r3.xlarge と 16 x r3.large
 
時間が経過し、スポット価格の上昇でインスタンスが割り込まれた場合は、必要なリソースを補うだけの代替インスタンスが起動されます。この場合、皆さんのアプリケーションは、インスタンスタイプ(と使えるメモリ用)を検知して調整する必要があります。フリートは、利用可能なリソースを使って指定されたキャパシティを達成するために、最大のインスタンスを余分に確保するかもしれません。先ほどの例では、512GiBのフリートキャパシティをリクエストした時に起こります。また、小さなリクエストや、大きなインスタンスが最安値の(ユニット毎の)価格だった場合にも起こります。
 
ユニットについて
ユニットは事前に決められており、インスタンスの属性と直接マッピングする必要はありません。皆様は、いくつかベンチマークをして、インスタンスタイプ毎のトランザクションレート (TPS)を計測していると思います。必要なTPSを処理できるフリートキャパシティをリクエストでき、その時点で最も経済的なEC2のインスタンスタイプが提示されます。以前に指摘した通り、Spotのメカニズムはテクノロジーとビジネスの交差点にあります。そして、皆様のビジネスの経済性を改善するコードを書く能力を提供します。(オンデマンド価格よりも90%以上コスト削減するために)創造的で革命的な余地が沢山あります。このメカニズムを使うことで、希望するアベイラビリティゾーンのWeightedCapacityの値を高めて、アベイラビリティゾーンの優先度を制御することもできます。例えば、同じインスタンスタイプで複数の設定をしておき、異なるアベイラビリティゾーンに対して異なるウェイトを設定することができます。
 
リクエストは AWS Command Line Interface (CLI) を使うか、RequestSpotFleetAPIを呼び出してください。
 
すぐに利用できます
この新機能は、本日よりSpotが利用できる全リージョンで利用可能です。
 
— Jeff;
 
 
(日本語訳は松尾が担当しました。原文: New – Resource-Oriented Bidding for EC2 Spot Instances

【AWS発表】Amazon RedshiftにUDF(ユーザ定義関数)が追加されました

$
0
0

Amazon Redshiftチームは絶好調です。彼らはお客様のフィードバックに耳を傾け、新しい機能を常にリリースし続けています!以下は、強く待ち望まれていた強力な新機能についてのアナウンスです。

— Jeff;


Amazon Redshiftはペタバイトまでスケール可能なデータウェアハウスを簡単に起動する事ができます。Amazon Redshift側でインフラを管理してくれるため、ユーザは運用を気にすることなく、$1,000/テラバイト/年以下の安価な利用費用で分析に集中することができます。Amazon Redshiftの価格とパフォーマンスは、お客様が多様なデータを分析することを可能にし、お客様自身のビジネスの理解を深めることを手助けします。YelpAmplitudeCakeのブログに書かれているように、私達のお客様は、データウェアハウスをスケールさせる事によって可能になる範囲を広げ続けています。

Amazon Redshiftの利便性を向上させ、お客様の新しいインサイト(洞察)をより簡単に得られるようにする機能として、Amazon Redshiftにユーザ定義関数(user-defined functions: UDF)を発表できることを嬉しく思います。PostgreSQLのUDFと同じシンタックスで、カスタム版Python 2.7を使ってスカラーファンクションを作成することができ、クラスターの中で並列に実行することができます。

以下がUDFを作成する際のひな形です:

CREATE [ OR REPLACE ] FUNCTION f_function_name 
( [ argument_name arg_type, ... ] )
RETURNS data_type
{ VOLATILE | STABLE | IMMUTABLE }
AS $$
  python_program
$$ LANGUAGE plpythonu;

スカラーUDFはビルトイン関数のROUNDSUSTRING等と同様に、1つの結果をそれぞれのインプットに対して返します。一度定義するだけで、任意のSQLの中でビルトイン関数と同様にUDFを利用可能になります。

独自のUDFを作成する際にはPythonライブラリーにある膨大なPython関数を活用してSQLで記述することが難しい処理を容易に記述することが可能です。またユーザ自身のカスタムライブラリーをS3やWebから直接追加して利用することも可能です。Amazon RedshiftのUDFには、最初からPython標準ライブラリ(※訳注:日本語ドキュメントはこちら)が用意されており、準備作業無しで使うことが可能です。さらに、標準ライブラリ以外の以下のライブラリを含んでいます:

  • NumPy, SciPy:これらは数学的な処理を提供します。多次元オブジェクトを作成し、行列処理をし、最適化アルゴリズムを実装し、統計処理を実行することができます。
  • Pandas:NumPyとSciPyの上に構築されたハイレベルデータ操作ツール。データ分析やエンドツーエンドのモデリングワークフローを実行することができます。
  • DeteutilPytz:これらは日付とタイムゾーンの操作を容易にします(例えば、次のうるう年での復活祭(Easter)まで何ヶ月あるか、といった計算が可能です)。

UDFは複雑な操作をシンプルに実装できます。例えば、URLからホスト名を抽出したい場合、以下のように正規表現を利用することができます:

SELECT REGEXP_REPLACE(url, '(https?)://([^@]*@)?([^:/]*)([/:].*|$)', ‘\3') FROM table;

もしくは、PythonのURLパースライブラリであるURLParseモジュールをインポートしてホスト名を抽出する関数を書くこともできます:

CREATE FUNCTION f_hostname(url VARCHAR)
RETURNS varchar
IMMUTABLE AS $$
import urlparse
return urlparse.urlparse(url).hostname
$$ LANGUAGE plpythonu;

こうすることでSQLで以下のように記述が出来るようになります:

SELECT f_hostname(url) 
FROM table;

お客様はご存知のように、Amazon Redshiftはセキュリティをとても重視しています。UDFは、完全に分離された制限付きのコンテナの中で実行されています。つまり、UDFによってクラスターを異常停止させたり、不正な処理でパフォーマンスにネガティブなインパクトを与えることは出来ないようになっています。加えて、関数の中からファイルやネットワークにアクセスすることは出来ないようになっています。このように強い管理状態に置かれているにも関わらず、UDFはAmazon RedshiftのMPP(massively parallel processing:超並列処理)を活用でき、各ノードで並列実行されることにより、パフォーマンスを最大化します。

UDFの作成方法や使い方を知るには、オフィシャルのドキュメントをご覧ください。またAWS Big Data blogの詳細な投稿も参考にしてください。また、APNパートナーのLookerが書いたハウツーガイドも参照してください。もし、作成したUDFを他のお客様とシェアしたいということであれば、ぜひredshift-feedback@amazon.comまでご連絡ください。APNパートナーのPeriscopeはすでに複数の有用なスカラーUDFを作成してこちらで公開しています。

これから2週間にかけて、クラスターにこの新機能が順次展開されていく予定で、いつ適用されるかはご利用のリージョンとメンテナンスウィンドウのセッティングに依存します。新機能が利用可能になったクラスターはバージョン1.0.991になります。私達は多くの方々がUDFを心待ちにしていただいていた事を知っていますし、辛抱強くお待ちいただいた事に感謝いたします。引き続きフィードバックをredshift-feedback@amazon.comにてお待ちしております。

Tina Adams, Senior Product Manager


(付記)このUDFを事前にご評価していただいていた日本のお客様からエンドースを頂いていますので、ここで紹介します。

Amazon RedshiftのUDFは待望の機能です。

UDFが追加されたことでテキストマイニングやパス分析のような高度な分析が可能になるでしょう。

UDFによってRedshiftの果たす役割は大きく拡大するはずです。

クックパッド株式会社

エンジニア

青木 峰郎 様

 

なお、上記翻訳にあるようにこの新機能はこれから2週間かけて各リージョンに展開されていく予定で、東京リージョンには本稿執筆時点ではまだ展開されていません。しかし他リージョン、例えばオレゴン(US-WEST-2)にはすでに展開されていますので、オレゴンで新しくクラスターを立てていただければUDFを作成する事が出来ます。ぜひお試しください!

翻訳:下佐粉 昭

原文:https://aws.amazon.com/jp/blogs/aws/user-defined-functions-for-amazon-redshift/

AWSを利用してMicrosoft Windows Server 2003のサポート終了(EOL)を乗り越える

$
0
0

以下のゲスト記事では、わたしの同僚であるBryan NairnNiko PamboukasがまだWindows Server 2003でアプリケーションを動かしている方のためのいくつかの選択肢について紹介します。

— Jeff;


 

多くの方がすでにご存じのとおり、2015年7月14日にマイクロソフトはWindows Server 2003の延長サポートを終了しました。マイクロソフトはオペレーティングシステムのサポートライフサイクルを公開して保守することにより製品のサポート有効期限を明示しています。オペレーティングシステムが一定の期間を経過して、延長サポートが終了すると、マイクロソフトはセキュリティやその他のアップデートの提供を中止します。

Windows Server 2003のもともとのリリースから12年が経過してもいまだにたくさんのビジネスで重要なアプリケーションやワークロードがWindows Server 2003ファミリー製品上で稼働しています。もしあなたの組織でまだWindows Server 2003ベースのワークロードが稼働していたとしても、決してひとりではありません。いくつかの業界専門家は1000万台以上のサーバーで2003が稼働していると推測しています。これらのうちいくつかのワークロードは仮想化されているものの、多くはベアメタル上にインストールされています。多くの場合これらのワークロードはオリジナルのハードウェア上で稼働しており利用している物理サーバーは耐用年数の終了が近づいています。

マーケットで入手できる最新のハードウェアはかならずしもWindows Server 2003と互換性はないため、購買の決定はややこしくなります。同様に、新しいオペレーティングシステムのバージョンへの移行は、あたらしいOSに既存のハードウェアのドライバがあるとは限らないため、新規ハードウェアの購入を必要とするでしょう。

Windows Server 2003インフラストラクチャをどうすべきかを検討することはあなたにとっても、そしてほかの多くの組織にとってもチャレンジとなります。移行の計画と実行には時間がかかることをわれわれは理解しており、そのために役に立つことができます。32ビットアプリケーションをクラウドで保持するのか、モダンなMicrosoft Windows Serverオペレーティングシステムに移行するのかまたはレガシーアプリケーションを書き直すのかにかかわらず、AWSは移行計画のための実用的な選択肢を提供することができます。

こちらがWindows Server 2003を移行するストラテジーを評価、計画そして実行するために役立つアイデアとリソースです。

32ビットアプリのクラウドへの移行

 32ビットアプリケーションはクラウドで動作しないというのは一般的な誤解です。Amazon Elastic Compute Cloud (EC2)は32ビットインスタンスを提供しておりすぐに利用可能です。32ビットのWindows Server 2003またはWindows Server 2008のAmazon Machine Image (AMI)ではじめることもVM Importを利用して自分のWindows仮想マシンイメージをEC2にもってくることもできます。これらの選択肢によりアプリケーションの移行に取り組む間に32ビットにとどまるための十分な時間ができます。

32ビットアプリケーションを64ビットインスタンスタイプで動かすこともできます。それによってPAEによる4GB以上のメモリにアクセスすることも追加オプションとしてできるようになります。この機能を利用するためには、AWS Developer Supportへのコンタクトが必要になるでしょう。

モダンなオペレーティングシステムへの移行

現在32ビットのWindows Server 2003または2008のEC2インスタンスを稼働していて移行準備ができているのであれば、いまが最新バージョンにする最適な時期です。AWSはWindows Server 2003からあたらしいWindowsオペレーティングシステムへのインプレースアップグレードをサポートします。OSアップグレードの詳細についてはEC2 Windows upgrade documentation pageを参照してください。ドキュメントに記述されているように、このプロセスはOSがアップグレードされたあとにリモートデスクトップでアクセスできるようインスタンス上のネットワークドライバをアップデートします。

レガシーアプリのモダナイズ

レガシーなWindows Server 2003アプリケーションをモダナイズするプロセスをはじめる準備ができていれば、数回のクリックで必要なリソースを見つけることができます。 AWSにはアプリケーションのあたらしいバージョンのWindowsへの移行を手助けするための広大なパートナーネットワークがあります。AWS Windows and .NET Developer Centerはツール、ドキュメンテーション、およびコードサンプルを提供しています。AWS SDK for .NET(独自ライブラリ、コードサンプル、およびVisual Studioテンプレートがふくまれます)によりWindowsと.NETでのアプリケーションの構築を容易にします。Visual Studioのユーザーであれば、AWS Toolkit for Visual Studioを使用することによりかんたんにSDKをはじめられます。よりくわしい情報はEC2 Developer Resources pageから見つけられます。 さらにCommunity ForumAWS on GithubにいくとAWS上でWindowsや.NETを動かしている開発者のコミュニティにつながって参加することができます。 

Windows Server 2003アプリケーションの移行に支援が必要であれば、AWSはtechnical documentationAWS Support Center、そしてAWS partnersへのアクセスなどさまざまなレベルのサポートを提供します。クラウドマイグレーションサービスに特化したAWSパートナーはどのアプリケーションを移行する必要があるかの評価や、再デプロイなしにサポートされないアプリケーションを移行するとき、スムーズな移行のために必要なリスク、ギャップや修正の特定を支援します。

ニーズに応じたプラットフォームとしてのAWS

 Windows Server 2008やWindows Server 2012がよりセキュアでより多くのソフトウェアソリューションをサポートするのに加えて、オンプレミスのインフラストラクチャからクラウドへの移行は追加の利点をもたらします。AWSクラウドはコスト効率のよい、柔軟でセキュアなクラウドコンピューティング環境を提供するように設計されています。ビジネスがもとめるリソースをプロビジョンして、使った分だけの支払いですむためAWSへの移行によるコスト削減効果は素晴らしいものがあります。加えて、Amazon Virtual Private Cloudによってリソースを展開できる独自の論理的に独立したネットワークを作成することにより、セキュリティの追加レイヤーを提供します。VPCによってIPレンジの特定や、どのインスタンスをインターネットにさらしてどれをプライベートにするのかの指定ができます。

今日からはじめる

先に述べたように、計画プロセスをはじめるにはいまが最適な時でわれわれはそのために役立ちます。疑問を抱いたときに役に立つように、移行作業についてより多くの詳細をカバーしているWindows Server 2003に関するよくある質問Windows Server 2003サポート終了のページを参照してください。われわれはWindows Server 2003からの移行が困難であることを認識していますが、AWSがその手助けとなればと思います。

— Bryan Nairn (Senior Product Manager) and Niko Pamboukas (Senior Product Manager)

(翻訳はSA渡邉が担当しました。原文はMoving Past Microsoft Windows Server 2003 End-of-Life Using AWS

週刊AWS - 2015年9月7日

$
0
0

9月ももう半ば、秋の色が濃くなってきました。暑さも和らいで、気楽に外出ができるようになってきましたね。出先で時間調整のためにカフェに入ると必ず冷たいドリンクをオーダーしていたのですが、暖かいものに切り替える時期もそろそろでしょうか。

秋といえば、やはりサンマが思い浮かぶのではないでしょうか(きのこも好きですが)。お刺身も塩焼きも美味しいので、メニューにのっているとついつい注文してしまいます。やはり私にとっての秋は、食欲の秋のようです。

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 

9/7(月) 
9/8(火)
9/9(水)
9/10(木)
9/11(金)

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

このブログの最新情報はTwitterでお知らせしています。お気軽に@awscloud_jpをフォローください。
----
ソリューションアーキテクト 小林正人

Spotフリートの新オプション- 複数のキャパシティプールに分散するフリート

$
0
0
先週、 Pacific Northwest PHP Conferenceにて、技術的な聴衆に向けて話をしました。私のパートでは、技術とビジネスのミックスとしてのクラウドコンピューティングと、その考えを裏付ける Spot instancesの説明をしました。聴衆は最初少し戸惑っていましたが、説明が進むにつれて、彼らの目が上を向き始め、創造的なコーディングによって企業のコスト削減の方法について考え始めました!
 
今年のはじめに、 Spot Fleet API(日本語訳)について書き、 RequestSpotFleet というひとつのAPIコールで、数千ものスポットインスタンスをどのようにマネージするかを紹介しました。本日、このAPI用の新しい”配置戦略”オプションを紹介します。このオプションで、複数のキャパシティプール(特定のリージョン、アベイラビリティゾーンに指定したインスタンスタイプ群)から抜き出したインスタンスでSpotフリートを構成できるようになります。
 
1度のRequestSpotFleetのAPIコールで、最大20の起動設定(launch specifications)を指定できます。アベイラビリティゾーンやサブネットを指定しないリクエストの場合、単一のAWSリージョン内の複数のキャパシティプールを指定できます。これにより、多くのEC2キャパシティを選択でき、アプリケーションに最適なフリートを構成できます。
 
以下の様な配置戦略を設定できます:
 
  • lowestPrice – デフォルトの戦略です。リクエストで指定したプールの中で、最安値のプールからインスタンスを選択しフリートを構成します。
  • diversified – 新しい戦略です。リクエストで明示的に指定する必要があります。その時点でのスポット価格がオンデマンド価格を上回っているプールを除いた、指定された全てのプールからインスタンスを選択しフリートを構成します。
 
このオプションで、各Spotフリートを最も最適にする戦略を選べるようになります。下記の表をガイドとして使ってください:
 lowestPricediversified
フリートサイズ小さめのフリートに適している。ただし、大きいリクエストによって最安値のプールの価格に影響をおよぼす比較的大きなフリートに適している
フリートの総コストプールの価格が急騰した場合には予測できないほど高くなる平均してオンデマンドの70%-80%.
単一プールの価格変動による影響フリートの全インスタンスが停止され、再入札が行われる変動したプール(フリートの全キャパシティの1/N)が変動による停止の影響を受け、再入札が行われる
アプリケーション特性短時間実行、処理待ちに寛容長時間実行、処理待ちに厳格
典型的なアプリケーション科学シミュレーション、研究計算トランスコーディング、ユーザがアクセスするWebサーバ、HPC、CI/CD
 
もしdiversified 戦略を使ってフリートを作成しウェブサーバとして使うなら、複数のプールを選択しつつ、全プールが使えなくった場合の方法を用意しておくと良いです。
 
diversified配置は、先月ローンチした新しいリソース志向入札機能と連携して機能します。リソース志向入札とdiversified配置を使うと、指定した各キャパシティプールで、同数のキャパシティユニットを使うことになります。
 
この新しい戦略を使うには、CLIもしくはAPIリクエストに組み入れるだけです。CLIを使う場合、単純に下記要素を設定ファイルに追加してください:
 
"AllocationStrategy": "diversified"
 
APIを使う場合、同じ値を SpotFleetRequestConfigDataに組み入れてください。
 
このオプションは本日より利用可能です。
 
— Jeff;(日本語訳は松尾が担当しました。原文:New Spot Fleet Option Distribute Your Fleet Across Multiple Capacity Pools)
 
訳注: ドキュメントの設定例も参照ください。Spot Fleet Example Configurations - Amazon Elastic Compute Cloud

【AWS発表】Route 53の改善 - ヘルスチェックの組み合わせ計算とレイテンシチェック

$
0
0

Amazon Route 53は、高可用性と拡張性のあるドメインネームシステム(DNS)Webサービスです。Route 53は、AWS(EC2インスタンス、ロードバランサ、およびS3バケット)で実行されているインフラストラクチャにユーザのリクエストを接続します。もちろん、AWS外のユーザーにも使用することができます。
Route53では定期的にヘルスチェックを実行し、チェックが失敗した場合、代替エンドポイントにフェイルオーバーするように設定することができます。また、ヘルスチェックを使用して、Webサイトやアプリケーションを監視したり、警告したりするシステムを作成することができます。

今日は、calculated(組み合わせ計算)とレイテンシ測定という2つのタイプのヘルスチェックを追加したことをお知らせします。

Calculated Health Checks

Route 53のヘルスチェック値の組み合わせについてAND、OR、そしてNOTをつかったBoolean計算を行うことができるようになりました。
他のチェックの結果を結合して単一のヘルスチェックを作成することができます。
例えば、私は同じEC2インスタンス上の3つのWebサイトを持っています。私はそれぞれのためのヘルスチェックを作成することから始めます。

R53_site_trio_1

 

次にインスタンスの全体的な状態を表す計算されたヘルスチェックを作成します:

R53_calculated_hc_1

スクリーンショットからわかるように、他のヘルスチェックの結果が全てヘルシーだと報告されたときだけにヘルシーだと報告するようなヘルスチェックを作成しました。
全てではなく、一部がヘルシーであればヘルシーとするようなことも作成できます。
誤検知を回避しつつ、メンテナンスのために1つのサイトをダウンさせることが可能になるでしょう。

この例では、同じインタンス上で実行されている3つの異なるドメインをチェックしていますが、そういう制約があるわけではありません。同じドメインでありながら、組織内の異なるグループによって管理されているウェブサイトのコンポーネントをチェックすることができます。あるいは、あなたのアプリケーションが依存している複数のドメインのウェブサービスを確認する情報をひとつに取りまとめることができます。

Latency測定ヘルスチェック

この機能では、TCP接続時間、ファーストバイトまでの時間、SSLハンドシェークの完了時間を測定することができます。1つめは、Route 53からエンドポイントへの接続確立までの時間を、2つめはデータ転送が実際に行われ始めるまでの時間を、3つめはSSL接続確立に必要な2ラウンドの時間を示します。

レイテンシ測定は、ヘルスチェックの一部として実行され、CloudWatchに送られます。レイテンシグラフの形で確認することもできます。

ヘルスチェックを設定しているレイテンシ測定を設定する方法は次のとおりです。

R53_latency_setup_1

コンソールに結果が表示されます。

R53_latency_ducks_1

デフォルトでは世界中にある32のRoute 53から確認された値の平均値が表示されます。もちろん、個別の値も確認できます。

今すぐ利用可能です

新しいヘルスチェックは今すぐ利用可能です。
価格の詳細は、Route 53のプライシングページを御覧ください。

本記事はhttps://aws.amazon.com/blogs/aws/route-53-improvements-calculated-health-checks-and-latency-checks/の翻訳です。翻訳は荒木が担当しました。


【AWS発表】Elastic Load Balancing のアップデート - 全ポートに対する負荷分散とアクセスログへのフィールドの追加

$
0
0

多くのAWSアプリケーションが、EC2インスタンス にトラフィックを分散する為に Elastic Load Balancingを使用しています。このタイプのアーキテクチャは、インスタンスの追加、削除、交換を安全に実施することが可能で非常にスケーラブルです。ロードバランサを使用することで、一部のインスタンスに問題が発生した場合にも、アプリケーションの実行を継続することができます。  

今日、私達はさらに便利な2つの新機能として、全てのポートに対する負荷分散とアクセスログに新たなフィールドを追加しました。

全ポートのサポート

新しいロードバランサを作成する際、1つ以上のリスナーを設定する必要があります。各リスナーは、特定のポートで接続要求を受け入れます。今までは、ウェルノウンポート(25、80、443、465、および687)の低位番号の小さなセットと、エフェメラルポート(1024-65535)の大きなセットの設定を行う必要がありました。

今日からは、VPC内で稼働するロードバランサは、どのようなポート(1-65535)に対してもリスニングが可能となります。これにより、低位のポート番号で動作する必要があるサービスに対してロードバランサを柔軟に構築することができます。

 これは、従来の方法(ELB APIAWSコマンドラインインターフェース(CLI) / AWS Tools for Windows PowerShellCloudFormationテンプレート、AWSマネジメントコンソール)で設定することができます。ここでは、ポート143(IMAPプロトコル)に対するロードバランサを定義する方法を紹介します。 

Elb_define_imap_load_balancer_1

詳細は、Elastic Load Balancing ドキュメントの”ロードバランサーのリスナー” を参照ください。

アクセスログの追加フィールド

 既に、ロードバランサを通過するトラフィックのログを S3に記録する機能は存在しています。

Elb_config_access_logs_2

より詳細にトラフィックについて知るため、また構成変更を検討する際に参考となる情報を得るために、現在、アクセスログには特定のプロトコルについていくつかの追加情報が含まれています。 

  • ユーザーエージェント - この値は、HTTPおよびHTTPSポートで受信したTCP要求が記録されます。 
  • SSL暗号とプロトコル - これらの値は、HTTPSとSSLポートで受信したTCP要求が記録されます。 

あなたが特定のWebブラウザ、暗号、またはSSLプロトコルのサポートを追加または削除するとき、これらの情報に基づいて意思決定を行うことができます。サンプル・ログ・エントリは次の通りです。

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000086 0.001048 0.001337 200 200 0 57 "GET https://www.example.com:443/ HTTP/1.1""curl/7.38.0" DHE-RSA-AES128-SHA TLSv1.2

また、この情報を表示、分析するために、AWSパートナーのツールを使用することができます。例えば Splunkではこのように表示できます。

Elb_splunk_new_fields_1

そして Sumo Logicではこのように表示できます。

Elb_sumo_logic_new_fields_overview_1

 

アクセスログの詳細については、開発者ガイドの"Elastic Load Balancing アクセスログを使用してロードバランサーを監視する"を参照下さい。

これらの両方の機能が利用可能となり、今日から使用を開始することができます!

-- Jeff (翻訳は辻正史が担当しました。原文はこちらです。)

 

AWS ストレージアップデート - S3 の新しい低コストなストレージオプション & Glacer の値下げ

$
0
0

全ての AWS サービスと同様に、Amazon S3 のチームはお客様の声をお聞きして、よりニーズを理解するように努めています。多くのフィードバックからの学びと過去のアクセスパターンの分析から、まれにしかアクセスされないデータに適した新しいストレージオプションを提供するのが望ましい状況だとわかりました。

チームは、多くの AWS のお客様がほとんど読み出す事が無いバックアップやログファイルを保管されている事を見つけました。その他、共有ドキュメントや後ほどすぐ分析する RAW データがアップロードされていました。これらのファイルは一般的に、アップロードされた直後は頻繁にアクセスされますが、その後はアクセスされなくなります。ほとんどのケースでこれらのデータは引き続き重要なため、耐久性は必須です。このようなストレージ用途は低頻度アクセスと分類されますが、ファイルにすぐアクセスできる事も必要なため、これまでのように取り出し性能も重要なままです。

新しい不定期アクセスのストレージオプション

このようなお客様のニーズを満たすために、低頻度でアクセスされるデータのための新しいストレージクラスを追加します。

新しいストレージクラス「S3 標準 - 低頻度アクセス (標準 - IA)」は、S3 標準と同じ高い耐久性、低い遅延、高いスループットを提供します。設計上の耐久性が 99.999999999% (イレブンナイン) である S3 のストレージクラスに 3 つ選択肢(標準、標準 - IA、Glacier)があるようになりました。標準 - IAの可用性 SLA は 99% です。

新しいストレージクラスはご存知の既存の S3 機能(セキュリティとアクセス管理の機能、ライフライクルポリシー、クロスリージョンレプリケーション、イベント通知を含む)全てを継承しています。

標準 - IAの料金は、「$0.0125 / GB / 月」の容量課金と「最小 30 日間分の課金」「(通常のデータ転送料やリクエスト課金に加え)取り出し $0.01 / GB 」で構成されます。加えて、課金上は 128 KB 未満のオブジェクトも 128KB の容量課金とさせて頂きます。長期保管、バックアップ、災害対策のような用途でとても経済的でありつつ、必要があればすぐに古いデータを取り出すこともできる課金体系になると考えています。

一定時間経過後にデータを Amazon S3 のストレージクラス間で移動するようにライフサイクルポリシーを定義する事ができます。例えば、アップロードしたばかりの時は標準ストレージクラスを使うことができ、アップロード後 30 日経過した後からは標準 - IA に移動し、さらに 60 日経過後には Amazon Glacier に移動するようにできます。

新しい標準 - IA ストレージクラスは、各 S3 オブジェクトに関連付けられた単純に属性の 1 つです。標準 - IA として転送した場合も、既存の S3 バケットのまま、同じ URL からアクセスする事ができるため、アプリケーションコード変えなくてもライフサイクルポリシーを使うことですぐに標準 - IA を使い始めて頂くことができます。つまり、アプリケーションへの変更やパフォーマンスへの影響をあたえること無く、ポリシーを追加することですぐに S3 のコストを削減できることを意味しています。

マネージメントコンソールで新しいオブジェクトをアップロードする際に、新しいストレージクラスを選択する事ができます。(今日から全てのリージョンでお使いいただけます):

ライフサイクルルールは各 S3 バケット毎に設定することができます。以下は、上記で説明した例を実現するためのポリシーになっています。:

これらの機能は AWS コマンドラインインターフェイス (CLI)、AWS Tools for Windows PowerShell、AWS SDK、S3 API でも利用できます。

新しいストレージクラスについての完全な料金情報については、S3 の料金ページを確認ください。

Glacier ストレージの値引き

2015 年 9 月 1 日より、Amazon Glacier の保存容量についての料金を $0.01 / GB / 月 から、$0.007 / GB / 月に値下げを行います。いつもの通りこの値引きは自動的に適用され、メリットを得るために何も実施頂く必要はありません。この価格は米国東部(バージニア北部)、米国西部(オレゴン)、EU(アイルランド)リージョンのものです。他のリージョンについては、Glacier の料金ページを確認ください。

— Jeff; (翻訳は辻が担当しました。原文:AWS Storage Update – New Lower Cost S3 Storage Option & Glacier Price Reduction)

【AWS発表】Amazon Cognitoが東京リージョンで利用可能になりました

$
0
0

ソリューションアーキテクトの西谷(@Keisuke69)です。

本日、Amazon Cognitoが東京リージョンでも利用可能となりました。皆様より非常に多くのご要望を頂いていましたので私も嬉しいです。

Cognito

Amazon Cognitoはモバイルアプリ開発におけるユーザIDとアクセスの簡略化と、クロスデバイス/クロスプラットフォームでのデータ同期を可能とするサービスです。Amazon Cognitoを利用することでモバイルアプリ開発におけるいくつかの課題を解決することができ、開発者はより本質的な問題の解決に取り組めます。例えば、Amazon CongitoのIdentity機能では各種ログインプロバイダと連携して、デバイスやプラットフォームをまたがってユニークなアイデンティティを生成し管理することが可能です。いっぽうSync機能ではこのユニークなアイデンティティをもとにKey-Value形式の任意のデータをデバイス間およびクラウド上のストレージ間で簡単に同期することが可能です。

なお、Amazon Cognitoは他にもUS East (N. Virginia)、EU (Ireland)のリージョンでも利用可能です。詳細な情報についてはプロダクトページをご覧下さい。

では、改めてAmazon Cognitoでできること、機能について簡単におさらいをしたいと思います。

Amazon Cognito Identity

Amazon Cognitoの大きな機能の1つがこのAmazon Cognito Identityです。パブリックなIDプロバイダや独自の認証システムと連携してCognito Identityの機能を利用することで、デバイスやプラットフォームをまたがったユニークなアイデンティティを生成することができ、任意のポリシーを持った一時的なクレデンシャルが発行することが可能です。現在サポートされているパブリックなIDプロバイダは、Amazon、Facebook、Twitter/Digits、Google+そしてアイデンティティの認証におけるオープン・スタンダードであるOpenID Connect(OIDC)に準拠するプロバイダです。また、これらのパブリックなIDプロバイダではなく独自に実装した認証システムを利用することもでき、これにより独自のユーザとパスワードで認証した上でAmazon Cognitoと連携するといったことが可能となります。また、特徴的な機能としてゲストユーザ(Unauthenticated Identityと呼ばれます)をサポートしており、認証の前後で権限を切り替えたりデータを引き継ぐといったことが可能です。

Amazon Cognitoを利用することで必要な権限だけを付与された一時的なAWSクレデンシャルを取得することができるため、アプリ内にクレデンシャル情報を静的に埋め込む必要がなくなりセキュリティのベストプラクティスが簡単に実現できます。従来、セキュアにAWSサービスを利用するためのベストプラクティスとしてAWS Security Token ServiceならびにToken Vending Machineを個別に実装することをご案内していましたが、Amazon Cognitoを利用することでこれらを用意することなくセキュアにAWSサービスを利用することが可能となります。アクセス制御にはAWS Identity and Access Management(IAM)を用いることでAWSリソースへの細やかなアクセス制御を実現できます。

Amazon Cognito Sync

もう1つの大きな機能がAmazon Cognito Syncです。Amazon Cognito Syncを使えばアプリケーションの設定やゲームの状態など、あらゆる種類のデータを AWSクラウドに保存し、クロスデバイス、クロスプラットフォームで同期することが可能です。バックエンドのコードを書くことや、インフラストラクチャの構築・管理は必要ありません。データはまずローカルのデータストアに保存されるため、モバイルで課題になりがちな、電波状況が不安定であったり不通であったりした場合にもシームレスに動作させることが可能です。また、ローカルとクラウド間の同期処理はデータのバージョンを比較してプッシュもしくはプルが行われるインテリジェントな仕様となっています。加えてコンフリクトが発生した場合は標準では最後の書き込みを有効として保存されますが、開発者で独自に実装することも可能です。これにより、開発者はネットワークの状態、ストレージ、同期を処理するバックエンドの構築や管理から解放され、優れたアプリケーション体験の開発に集中できます。

Push Sync

Amazon Cognito SyncはAmazon SNS Mobile Pushと連携することも可能です。Amazon Cognitoのデータストアが更新されたタイミングで、各デバイスにプッシュ通知を送信できます。これによりプッシュ通知を受け取ってからデータストアの再同期を行えるようにできるなどより効率的な実装が行えます。例えばこの場合は無駄な通信を削減することができるためバッテリーの節約につながります。

Amazon Cognito Streams

Amazon Kinesisとの連携も可能です。データが更新されたり、同期されたことをイベントとしてAmazon KinesisのStreamで受け取るように構成することができます。KCL(Kinesis Client Library)を利用したKinesisアプリケーションを用意したり、AWS LambdaのファンクションとしてKinesisアプリケーションを実装することでAmazon Cognitoに保存されたデータをリアルタイムに操作したり調査したりできるようになります。 

Amazon Cognito Events

Amazon Cognito Eventsにより、Amazon Cognitoにおける重要なイベントに呼応してAWS Lambdaのファンクションを実行することが可能です。データセットが同期されるとSync Triggerが発火されます。クラウド上や他のデバイスに保存される前にデータを操作したりすることが可能です。これにより保存されるデータのバリデーションを行ったり、同期されるデータを元に別のデータを更新する(例えばレベルを上げるなど)などといったことが行えます。

料金と無料枠

Amazon Cognitoの料金は同期用のデータストアに保存されたデータの合計量と同期オペレーションの実行回数によって決まります。また、無料利用枠が用意されており最初の12か月間、1か月につき10GBのデータストア容量と100万回の同期オペレーションを無料で利用可能です。無料利用枠を超えた場合は同期オペレーション1万回につき 0.15USD、データストアの容量1GBにつき毎月0.15 USDが請求されます。

最後に

Amazon Cognitoの東京リージョンでのローンチを記念して、毎週開催しているAWS Black Belt Tech Webinarにて最近お馴染みとなりつつある緊急特番を開催する予定です。
今のところ9月28日(月)の12時〜13時を予定しています。詳細は参加登録のご案内は別途行いますのでぜひともご参加ください。
講師はもちろん私、西谷が行います!(同じくソリューションアーキテクトの清水もいるかも知れません)

- 西谷圭介(@Keisuke69)

Amazon Linux AMI 2015.09 公開

$
0
0
私の同僚であるMax Spevackは Amazon Linux AMIを開発しているチームを率いています。彼による最新版リリースのアナウンスです!
— Jeff;

Amazon Linux AMI は  Amazon EC2をサポートしメンテナンスされているLinuxイメージです。
 
複数のリリース候補版でのパブリックテストのフェーズを経て、メジャーバージョンを本日リリースしました。リリース候補版はEC2フォーラムで告知しており、フィードバックを受け付けています。
 
本日 2015.09をリリース
本日、2015.09 Amazon Linux AMIのリリースをお知らせします。これには全リージョンと全ての現行世代EC2インスタンスタイプをサポートしています。Amazon Linux AMIはPVとHVMの両方をサポートし、さらに、EBS-Backedとインスタンスストアの両方のAMIをサポートします。
 
新しいバージョンのAMIは通常の手順で起動できます。既存のEC2インスタンスも以下のコマンドでアップグレードできます:
$ sudo yum clean all  && sudo yum update

実行後にインスタンスをリブートしてください。

 
新しいカーネル
このリリースの新機能の目玉は、 最新の長期安定リリースカーネルである4.1.7 kernelです。多くのお客様が関心を寄せている、4.xカーネルシリーズのOverlayFSをサポートしています。
 
新機能
 Amazon Linux AMIのロードマップの大部分は、お客様のご要望で決まります。リリースサイクルにて、これらのご要望の結果として多くの機能を追加しています。以下に例を示します:
  • 多くのお客様からのご要望とLinuxインスタンスのSimple ADへの参加 (AWS Directory Service)をサポートするために、Samba 4.1をAmazon Linux AMIリポジトリに追加しました。 sudo yum install sambaで利用可能です。
  • 多くのお客様から問い合わせ頂いていたPostgreSQL 9.4 を、PostgreSQL 9.2や9.3と別にAmazon Linux AMIリポジトリに追加しました。PostgreSQL 9.4は sudo yum install postgresql94 で利用可能です。2015.09 Amazon Linux AMIリポジトリでは PostgreSQL 9.4.4を追加しています。
  • よくご要望頂いていたMySQL5.6を、MySQL5.1や5.5と別に 2015.09リポジトリに追加しました。MySQL5.6は sudo yum install mysql56 で利用可能です。2015.09 Amazon Linux AMIリポジトリでは MySQL5.6.26を追加しています。
  • 以前、Docker とGoを 2014.03 AMIに追加した後も、継続してこれらのリリースに追従しています。2015.09リリースでは Go 1.4Docker 1.7.1を追加しています。
  • Amazon Linux AMIには既にPython 2.6, 2.7 (デフォルト), 3.4が使えますが、一部のお客様からは PyPy実装についてお問い合わせ頂いていました。本日、プレビューリポジトリにPyPy2.4を追加しました。PyPy2.4はPython2.7.8互換であり、sudo yum --enablerepo=amzn-preview install pypyで利用可能です。
  • 前回の2015.03リリースにて、プログラミング言語Rustの最初のプレビュー版を追加しました。この言語の開発に追従しており、2015.09リリースでは、Rust 1.0からRust1.2にアップデートしています。Rustコンパイラはsudo yum --enablerepo=amzn-preview install rustで利用可能です。
 
リリースノートでは、新機能とパッケージのアップデートについてもっと詳しく説明しています。このブログ公開にあわせて、(特にJeffに向けて)Emacsもアップデートバージョンを追加しています。
 
— Max Spevack, Development Manager, Amazon Linux AMI.
 
(日本語訳は松尾が担当しました。原文:Now Available – Amazon Linux AMI 2015.09 )

週刊AWS - 2015年9月14日

$
0
0

大変おまたせいたしました。ついに東京リージョンでもAmazon Cognitoがご利用いただけるようになりました!さっそくブログ記事を公開しておりますので、ぜひご覧ください。Amazon Cognitoの東京リージョンへの展開を記念して、Black Belt Tech Webinarの緊急特番を9月28日(月)の12時から開催する予定です。申し込みページは追って公開いたしますので、準備が整いましたらお知らせします。

9月24日追記:
申し込みページ
を公開いたしました。こちらのブログ記事からもリンクしていますので、あわせてごらんください。

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 

月曜日

9月14日

火曜日

9月15日

水曜日

9月16日

木曜日

9月17日

金曜日

9月18日

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

このブログの最新情報はTwitterでお知らせしています。お気軽に@awscloud_jpをフォローください。
----
ソリューションアーキテクト 小林正人

新しく追加したAWSパブリックデータセット– 3000イネゲノム

$
0
0
私の同僚のAngel Pizzaroによる、新しいAWSパブリックデータセットについて説明したゲストポストです!

— Jeff;


 
5つの異なる参照ゲノムと比較分析されたイネ3,024品種のゲノムシークエンスデータに、AWSパブリックデータセットとしてアクセスできるようになりました。このデータは3000万以上の遺伝子のバリエーションを含んでおり、これらの遺伝子を囲む潜在的な調節領域だけでなく、既知のイネ遺伝子と予測されているイネ遺伝子を含みます。 このデータを解析することで、研究者は、収穫量のような重要な農業特性に関連する遺伝子を特定できる可能性があります。
 
コメは世界人口の半数が主たる食料源としており、一人あたりのカロリーの20%以上を占めます。世界の人口増加に対応するため、コメ収穫量を2030年までに25%増産する方法を見つけ出す必要があります。特に気象変動や汚染が進行している傾向を考慮すると、従来の交配による収穫量の増加率では十分ではありません。世界中の安定した食料供給の要求を満たすには、遺伝子情報を考慮した現代的な交配手法が、コミュニティ全般で採用される必要があります。
 
3,000イネゲノムシークエンスプロジェクトは、89カ国から集めたイネ3,024品種の配列決定を行う国際的な作業です。協力した機関は、Chinese Academy of Agricultural Sciences(中国農業科学アカデミー)、 BGI Shenzhen(北京ゲノム研究所)と International Rice Research Institute (IRRI, 国際イネ研究所)です。5種類の公開されたイネゲノムのゲノムドラフト配列と、3,204品種のイネのシークエンスデータを分析するために、コンソーシアムはDNAnexusと提携しました。DNAnexusとの提携で、AWSのスケーラブルなコンピューティングキャパシティを使うことができました。37000コアをたった2日間だけ使い、手元の計算インフラより200倍以上高速に全ゲノムデータを処理します。加えて、追加の分析にもDNAnexus経由でデータを参照できます。DNAnexus内データを参照する方法の詳細は、プロジェクトドキュメントを参照してください。
 
データをより詳しく分析することで、より高い生産量と、害虫・病気・気候変動といったストレスへの耐性という結果に結びつきます。3000イネゲノムパブリックデータセットのページで、データとその参照方法についてより詳しく知ることができます。
 
AWS上のゲノムデータセットを使う
データはS3 にホストしており一般的なHTTPプロトコルでアクセスできるため、研究者は既存のツールと驚くような組み合わせを行っています。初期のいくつかの例をこれから示しますが、 IRRIと協力してより多くの例を共有するつもりです。
 
SNP-Seekを使ったデータ可視化
The International Rice Informatics Consortium (IRIC)では、SNP-Seekポータルでデータの検索と可視化を行えるようにしています。ユーザは全ての株を検索でき、イネ研究コミュニティのゲノムアノテーションデータと統合された複数の参照ゲノムから得た様々な結果から 目的のリージョンを絞り込む事ができます:
 
オープンソースツール
ゲノムデータを扱うには、ライフサイエンス分野のAWSパートナー群に加えて、オープンソースのエコシステムも利用可能です。samtools のようなコマンドラインアプリケーションから、 Galaxy や iobioといったリッチなユーザーインターフェースまであり、研究者がすぐにデータを解析することができます。

 
今後は?
研究コミュニティにとっての課題は、新種のイネを継続的に創ることを究極の目的として、網羅的かつ体系的にこのデータセットを採掘し遺伝子型変異を機能上変異に結びつけることです。すでにAWS上で参照可能なLandsatデータのような衛星画像に基づく研究環境と同じように、制御された環境や自然の環境での慎重な特性表現型のような他の研究と、これらの努力を組み合わせることで、将来の世界人口増加による需要に追従するのを助けます。
 
データを参照し、プロジェクトのアップデート受け取りのサインナップするために、3000イネゲノムパブリックデータセットのページにアクセスしてください。
— Angel Pizzaro, Technical Business Development Manager, AWS Scientific Computing 
(日本語訳は松尾が担当しました。原文:New AWS Public Data Set – 3000 Rice Genome )

【AWS発表】Amazon RDSアップデート - Oracle + ブラジル + 大きなボリューム + α

$
0
0

私はAmazon Relational Database Service (RDS)を、デモで実際に動かしてみせることが好きです。聴衆のみなさんは、私がMySQL、Oracle、SQL Server、PostgreSQL、もしくはAmazon Auroraデータベースインスタンスを数クリックで起動するのを観ると、その価値を理解してくれます。

本エントリでは、私達が最近RDSに追加したさまざまな機能をご紹介します。それぞれの機能ごとにはブログで紹介できていなかったため、最新情報では無いものもありますが、これら重要な機能追加を見逃していただきたくないと思っています。以下が紹介したい内容の簡単なサマリーです:

  • t2.largeデータベースインスタンスタイプが利用可能になりました。
  • Oracle 12.1.0.2および最新パッチが利用可能になりました。
  • R3およびT2データベースインスタンスがOracleで利用可能になりました。
  • R3データベースインスタンスがブラジルで利用可能になりました。
  • MySQL,Oracle,SQL Server,PostgreSQLのデータベースインスタンスで、より大きいストレージが利用可能になりました(データベースエンジンによりますが、最大4TB、もしくは6TB)。
  • データベースインスタンスに付けたタグがスナップショットにもコピーされるようになり、リストア時にインスタンスに付与されるようになりました。
  • SQL Server Enterprise Editionにおいて、ライセンス込みのオファリングが利用可能になりました。

t2.largeデータベースインスタンスが利用可能に

T2インスタンスはベースラインのCPU性能に加え、それ以上の性能をバーストで提供可能なインスタンスです。このインスタンスはフルのCPU性能を常時は必要としないワークロードに対し、M3データベースインスタンスと比較して低い価格で提供する事を目的にデザインされています。

既存のインスタンスタイプ(db.t2.micro、db.t2.smallおよび db.t2.medium)に加え、全てのデータベースエンジンで新しいdb.t2.largeインスタンスタイプが選択可能になりました。このインスタンスタイプはdb.t2.mediumと比較して2倍のメモリ、50%多いCPUクレジット/時間を提供します。このインスタンスはUS East (Northern Virginia), US West (Northern California), US West (Oregon), South America (Brazil), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Singapore),  China (Beijing)リージョンで利用可能です。

t2.largeはデータ保存時の暗号化をサポートしています。[詳細設定]の画面で設定することができます:

Oracle 12.1.0.2のサポート
RDS for OracleでOracleデータベース12cのバージョン12.1.0.2をサポートしました。これによりインメモリーオプションを使ってデータの一部をインメモリーカラムフォーマットに格納し、パフォーマンスを最適化することが可能になります。これは次で説明する新しく利用可能になったR3データベースインスタンスでの利用にとてもフィットします。

このアップデートには「April 2015 Oracle Patch Set Updates (PSU) for Oracle Database 11g and 12c」が含まれています。また、DBMS_REPAIRパッケージにアクセス出来るようになっています。AWS CloudHSMとのインテグレーションも強化されています。複数のRDSQLアカウントから1つのCloudHSMパーティションにアクセス出来るように改善され、1つのCloudHSMパーティション上にある複数のRDS Oracleデータベース用のTDEマスターキーを格納出来るようになっています。

現在、以下のOracleバージョンがRDSで利用可能です:

  • 11.2.0.4.v4
  • 12.1.0.2.v1
  • 12.1.0.1.v2

RDS for OracleがR3およびT2データベースインスタンスで稼動可能に

R3インスタンスはメモリ量を重視するアプリケーションに最適化されたインスタンスで、データベースインスタンスの種類において、メモリ1GiBあたりの費用が最も安く設定されています。このインスタンスは、高いメモリバンド幅と低いネットワーク遅延を提供しつつ、M2データベースインスタンスより最大28%低い価格で提供されています。

Oracleデータベースが、このR3およびT2インスタンスで利用可能になりました:

R3がブラジルで利用可能に

R3データベースインスタンスが南アメリカ(ブラジル)リージョンで利用可能になりました。MySQL,Oracle,SQL ServerおよびPostgreSQLデータベースエンジンで利用可能です。

より大きなサイズのストレージ
今年ストレージサイズの増加を発表したことで、Provisioned IOPS(PIOPS)、およびGeneral Purpose (SSD)ストレージをより大きなサイズで利用出来るようになりました。以下が新しい上限値です:

  • MySQL, PostgreSQL, Oracleデータベースでは最大6TB。
  • SQL Server データベースインスタンスでは、最大4TB、20,000IOPS(以前の2倍)。

インスタンスのタグがスナップショットに反映され、リストア時に戻されるように
データベースインスタンスにタグを付てスナップショットを取得し、そのスナップショットから新しいインスタンスを作成した場合に、新しいインスタンスにそのタグが適用されるようになりました。

ライセンス込みのSQL Server Enterprise
RDS for SQL ServerでSQL Server Enterprise Editionがライセンス込のオファリングで提供されるようになりました。言い換えれば、SQL Server Enterpriseライセンスを別途購入する必要はなく、RDSの利用料金の中にライセンス費用、ハードウェアリソースやRDSの各種機能が含まれているということです。(訳注:現時点では東京リージョンではRDS for SQL ServerでEnterprise Editionが提供されていません)

本日より利用可能です
これら新機能は現時点で(いくつかは1-2ヶ月前から)リリースされており、本日より利用可能です!

Jeff;

原文:https://aws.amazon.com/blogs/aws/amazon-rds-update-oracle-brazil-larger-volumes-more/

(翻訳:下佐粉 昭)


週刊AWS - 2015年9月21日

$
0
0

世界最大のAWSイベント、re:inventが来週に迫ってきました。参加のお申し込みは終了してしまっているのですが、ライブストリーミングをご用意しております。日本時間では早朝となりますが、リアルタイムで最新情報をゲットできるチャンスです。(re:inventのサイトからお申し込みいただけます)

また、日本チームではre:inventの内容をご紹介するウェビナーを企画しております。Black Belt Tech Webinarのre:invent特集と題しまして3回にわたって、切り口を変えながらご紹介いたします。このウェビナーは日本時間のお昼と夜の開催になりますので、早起きしなくてもご参加いただけます。今すぐお申し込みください!

それでは、いつものように先週AWSの世界で起こった出来事を振り返ってみましょう。 

月曜日

9月21日

火曜日

9月22日

水曜日

9月23日

木曜日

9月24日

金曜日

9月25日

また、今週も外部ブログにて数多くの興味深い記事がポストされております。

このブログの最新情報はTwitterでお知らせしています。お気軽に@awscloud_jpをフォローください。
----
ソリューションアーキテクト 小林正人

Elastic Beanstalk アップデート - JavaとGoのサポート

$
0
0

私の同僚であるAbhishek SinghはAWS Elastic Beanstalkのプロダクトマネージャーです。AWS Elastic BeanstalkがJava JARファイルおよびGoプログラミング言語をサポートしたことを皆様にお知らせするために、彼が以下の記事を投稿してくれました。

--Jeff;

AWS Elastic BeanstalkではすでにJava, .NET, PHP, Ruby, Node.js, およびDocker WebアプリケーションおよびサービスをAWS上でデプロイ、スケーリングするプロセスを簡素化しています。シンプルにコードをアップロードすると、Elastic Beanstalkが自動的にキャパシティプロビジョニング、 負荷分散、自動スケーリング、アプリケーションのヘルスモニタリングを含め、デプロイ処理を行います。同時に、あなたのアプリケーションを供給し続けるAWSリソースのフルコントロールが可能です。

本日、JavaとGoアプリケーションのサポートを追加することで、Elastic Beanstalkをさらに便利にします。さらに、新しいプラットフォームはweb層で動作するNginxリバースプロキシを構成するプロセスを簡素化します。 Nginxの構成を上書きするために.ebextensions/nginxフォルダー内にnginx.confを配置することが可能です。また、そのプラットフォームによって提供されるNginxの構成の中に含めるため.ebextensions/nginx/conf.dフォルダー内に構成ファイルを配置可能です。詳細はリバースプロキシの構成をご参照ください。

1. .ebextensions/nginx/nginx.conf - Nginx構成を上書きする
2. .ebextensions/nginx/conf.d - Nginx構成内に含められるファイル群

Javaの新しいサポート

JettyまたはPlayのようなサーバやフレームワークを使って、Javaのアプリケーションを動作させることが可能になりました。もはやJavaアプリケーション用にアプリケーションサーバとしてTomcatを使うよう制限されることはありません。

JavaアプリケーションをElastic Beanstalkへデプロイする方法は次の通りです。

開始するには、シンプルに新しいElastic Beanstalk環境を作成して、事前定義されたカテゴリにあるJavaプラットフォームを選択してください。 Java 7およびJava 8の両方がサポートされます。

 

Goの新しいサポート

また、AWS Elastic Beanstalk上でGo言語のアプリケーションを動作させることが可能になりました。次のような方法でElastic BeanstalkにGoアプリケーションをデプロイ可能です。

1. アプリケーションのソースを含むアーカイブをアップロード。AWS Elastic Beanstalkは自動的にアプリケーションをビルドして動作させます 。(AWS Elastic Beanstalkはapplication.goという名前のファイルにmain functionがあると想定します。)

2. アプリケーションのバイナリを含めたアーカイブをアップロード。こちらにアプリケーションを動作させるために必要な追加のコマンドラインパラメータを定義するProcfileも含めます。詳細はアプリケーションプロセス構成(Procfile)をご覧ください。

3. アプリケーションのソース、Buildfile、およびProcfileを含めたアーカイブをアップロード。詳細はサーバ上にアプリケーションをビルドする(Buildfile)をご覧ください。

Javaプラットフォームのように、GoプラットフォームはProfileに複数のプロセスを定義するこおでそれらの動作をサポートします。

新しいプラットフォームで利用開始するには、AWS Elastic Beanstalkマネ ージメントコンソールにログインする、あるいはEB CLIを利用して最適なプラットフォームを動作させる環境を作成してみてください。

--Abhishek Singh, シニアプロダクトマネージャー、AWS Elastic Beanstalk

本記事は舟崎が翻訳を担当しました。元の記事はこちらです。

[APN] AWSマネージドサービスプログラム認定取得の日本のパートナー様

$
0
0

コンサルティング パートナー部の相田です。本日はみなさまに嬉しいお知らせがあります。

日本国内のAPN(AWS Partner Network)パートナー様より、「AWS マネージドサービスプログラム(MSP)」の認定取得パートナーが3社を超えました!

AWS マネージドサービスプログラムの認定パートナーは今回の3社を含め、世界中で数千の登録のあるAPNパートナーから36社(2015年9月29日現在)となります。この認定はグローバル共通基準での第三者機関による厳密な審査をしておりますので、日本の認定取得パートナー様が世界基準を満たしている事を意味しています。

Mspprogram

AWSではAPN パートナーの皆様をサポートさせていただくプログラムとして、例えば以下のようなパートナー各社様の豊富な経験と実績を認定するプログラムを提供しています。

APN コンピテンシープログラム
各種ソリューションにおける、プログラム参加パートナーの高い専門性と導入実績を認定するプログラム。 

AWS マネージドサービスプログラム
クラウドインフラストラクチャおよびアプリケーションの移行のスキルを持ち、お客様の環境を積極的にモニタリング、自動化、管理することにより、お客様に価値を提供する APN コンサルティングパートナーを認定するプログラム。

AWS マネージドサービスプログラムは、同プログラムが要件とする実績条件に加え、AWSの運用サービスの提供についてAWS以外の第3者機関による監査プロセスを通過したAPNパートナーのみが認定されるプログラムです。

Logo

日本からは以下、APNプレミアコンサルティングパートナーである3社がその認定を受けています。

株式会社野村総合研究所

アイレット株式会社

株式会社サーバーワークス

       ※AWS マネージドサービスプログラム認定取得日順

 

 APNパートナープログラムにご興味を持っていただいた方は是非こちらよりご連絡をお待ちしております。
https://aws.amazon.com/jp/contact-us/aws-sales/

  

----------------------
パートナー アライアンス本部
コンサルティング パートナー部 部長
相田 哲也  

【AWS発表】Amazon SESがメール受信、そしてその処理に対応しました

$
0
0
振り返ること、2011年にAmazon Simple Email Service (SES)をリリースしました。これはメール受信者への到達性にフォーカスしたサービスです。現在、Amazonやお客様によって、年間数十億のやり取りがなされ、マーケティングメールに使われています。
 
本日、多くの要望がよせられていたSESの新機能をリリースします。SESをドメイン全体あるいは、そのドメインの個別のメールアドレスのメール受信に使うことができるようになりました。これによって、スケーラブルかつ高度に自動化されたメール送受信および処理システムを作ることができます。
 
洗練されたルールセットおよびIPアドレスフィルタをつかって、個々のメッセージの行き先をコントロールできます。ルールに適合したメールにヘッダを付加したり、S3バケットに格納したり、SNSトピックに誘導したり、Lambdaファンクションに渡したり、バウンスさせたりできます。
 
メール受信および処理
 
この機能を使うためには、使いたいドメインをあなたが保持しているかを確認しなければなりません。SESをメール送信に使っているのであれば、すでに準備はできています。
 
あなたにやってくるメールをSESに処理させるためには、メールを振り向けなければなりません。そのためには2つの方法があります。1つは、ドメインのMXレコードをリージョン別に用意されたSESのSMTPエンドポイントにふりむけることです。もうひとつは、すでに持っているメールシステムをSESのSMTPエンドポイントに転送することです。
 
次にやることは、そのメッセージに対して行いたいことの指定です。このために、受信ルールを作ります。ルールはルールセットとしてグループ化され、複数のドメインに適用することができます。他の多くのAWSサービスと同じく、ルールおよびルールセットはリージョン毎に個別に指定する必要があります。アクティブなルールセットはそれぞれのリージョンで一つだけです。そのルールがなければ、全てのメールは受信拒否(reject)されます。
 
ルールには次のような属性があります。
  • Enabled - このルールが有効か無効かのフラグ
  • Recipients - 適応するメールアドレスもしくは、ドメイン、およびその両方のリスト。この属性が与えられていない場合、ルールはドメイン全てのアドレスに適応されます。
  • Scan - スパムおよびウィルススキャンを行うかどうかのフラグ(デフォルトはtrueです)
  • TLS - ルールにマッチしたメールをTLSで暗号して渡すかどうかのフラグ
  • Action List - ルールにマッチしたメッセージにどのような処理をするかの、順番付きリスト。
 
SESがメッセージを受信すると、そのメッセージに続く処理を許可するかどうかのチェックをします。何が行われるかというと、
 
  • ソースIPアドレスは、SESが内部でメンテナンスしているリストと照合してrejectする(このリスト自体は、上書きすることができます)
  • ソースIPアドレスは、ユーザが作ったIPアドレスリストと照合してrejectする
  • メッセージは、ルール内のメールアドレスもしくはドメインと照合してacceptする
 
メッセージがルールに適合しなければ、課金は発生しません。いったんメッセージがacceptされれば、SESはルールしたがってアクションを起こします。アクションとしては、
 
  • Add: メッセージにヘッダを付与します
  • Store: S3バケットにメッセージを保存します。オプションで、AWS Key Management Service (KMS)内の鍵をつかった暗号化ができます。メッセージ全体(ヘッダおよび本文)は30MB以下でなければいけません。
  • Publish: メッセージをSNSのトピックに送ります。メッセージ全体は150KB以下でなければいけません。
  • Invoke: Lambdaファンクションを実行します。同期および非同期(デフォルト)で実行されます。
  • Return: 送信者にメッセージをバウンスします。
  • Stop: ルールのアクションを中止します。
 
アクションは、ルールの記述順に処理されます。Lambdaのアクションはspamおよびvirusスキャンの結果にアクセスします。Lambdaファンクションをメッセージ本文に適用するのであれば、先にメッセージをS3にStoreしなければなりません。
 
 
クイックデモ
 
受信メールをLambdaファンクション(MyFunction)に渡し、SNSトピック(MyTopic)に送り、さらにメッセージをKMSの鍵(aws/ses)で暗号化してS3(MyBucket)に保存するルールをつくることにします。
Ses_create_a_rule_1
 
自分のルールを一覧もできます
 
Ses_rule_set_1
 
SpamやVirusチェックの結果失敗した場合にその後の処理をとめるようなLambdaファンクションの例です。このファンクションを意図したように動作させるには、同期で実行します。
 
exports.handler = function(event, context) {
    console.log('Spam filter');
    var sesNotification = event.Records[0].ses;
    console.log("SES Notification:\n", JSON.stringify(sesNotification, null, 2));
    // Check if any spam check failed
    if (sesNotification.receipt.spfVerdict.status      === 'FAIL'
        || sesNotification.receipt.dkimVerdict.status  === 'FAIL'
        || sesNotification.receipt.spamVerdict.status  === 'FAIL'
        || sesNotification.receipt.virusVerdict.status === 'FAIL')
    {
        console.log('Dropping spam');
        // Stop processing rule set, dropping message
        context.succeed({'disposition':'STOP_RULE_SET'});
    }
    else
    {
        context.succeed();   
    }
};
 
更に詳しい情報は、 Amazon SES Developer GuideReceiving Email を御覧ください。
 
価格と利用
 
受信費用は1000通毎に0.10ドルです。メッセージは256KBまたは、256KBのチャンクとして、1000チャンク毎に0.09ドルが課金されます。たとえば768KBのメッセージは3チャンクとして数えます。また、S3やSNAあるいはLambdaに使ったリソースにも課金されます。詳細は、Amazon SES Pricingをご覧ください。
 
この新機能は今日から、US East(北バージニア)、US West(オレゴン)、ヨーロッパ(アイルランド)リージョンで使えます。
 
-- Jeff;
(本記事は https://aws.amazon.com/blogs/aws/new-receive-and-process-incoming-email-with-amazon-ses/ の翻訳です。翻訳は、荒木が担当しました)

【AWS発表】Amazon EMR リリース4.1.0 - Spark 1.5.0, Hue 3.7.1, HDFS暗号化, Presto, Oozie, Zeppelin, リサイズの改善

$
0
0

私の同僚のJon FritzとAhishek SinhaはEMRチームのシニアプロダクトマネージャです。彼らが以下の様に新しいEMRのリリースと新しいEMRクラスタのリサイズ機能を皆さんにお伝えするゲスト投稿を書いてくれました。

-- Jeff;


Amazon EMRは、Apache HadoopやApache Sparkといった分散データ処理フレームワークの実行と管理を簡単にしてくれるマネージドサービスです。

本日、我々はAmazon EMRリリース4.1.0をアナウンスします、これにはSpark 1.5.0、Hue 3.7.1、そしてHDFSのHadoop KMSを使った透過的な暗号化のサポートが含まれています。また、クラスタのノード数を減らす時に動作しているジョブに対する影響を最小化するインテリジェントなリサイズ機能もご紹介します。さらに、サンドボックスアプリケーションとしてPresto 0.119、Zeppelin 0.6(Snapshot)、Oozie 4.0.1が利用可能なこともアナウンスします。EMRサンドボックスは完全な一般利用可能(GA)リリースに向けて開発中のアプリケーションへの簡単なアクセスを提供します。

EMRリリース4.1.0はリリース4.0.0に続く最初のリリースとなります。リリース4.0.0では、アプリケーションの設定、新しいパッケージングシステム、Hadoopエコシステムアプリケーションの標準的なポートとパスへの変更、そしてAWSマネジメントコンソールでのクラスタのクイック作成オプションといった、多数のプラットフォームの改善が行われました。

4.xリリースシリーズの新しいアプリケーションとコンポーネント

Amazon EMRは、EMRのコンソール、AWS CLI、またはSDK経由でEMR APIを使ってクラスタを作成する時に、HadoopやSparkエコシステムの分散ビッグデータアプリケーションをインストールし設定する簡単な方法を提供しています。リリース4.1.0で、さらにいくつかの新しいアプリケーションのサポートを追加しました:

  • Spark 1.5.0 - 我々はEMRリリース4.0.0にSpark 1.4.1を含めましたが、今回のEMRリリースでSparkのバージョンを1.5.0に更新しました。Spark 1.5.0には多種の新しい機能とバグ修正が含まれていて、Spark SQL/Dataframeの機能追加、MLlibの新しいアルゴリズム、Spark Streaming向けのPython APIの改善、Parquet 1.7のサポート、そしてdynamically allocated executorsのロケーションの指定が含まれます。Amazon EMR上のSparkについてもっと詳しい情報については、こちらをクリックして下さい
  • HUE 3.7.1 - Hadoop User Experience (HUE)はオープンソースのユーザインタフェースで、Hadoopエコシステムアプリケーションでの開発やクエリ・ワークフローの実行や、Hive Metastoreのテーブルを表示、Amazon S3やクラスタ内のHDFSを閲覧することをより簡単にしてくれます。複数のユーザがAmazon EMRクラスタ上のHUEにログインして、Amazon S3やHDFSのデータに対してApache HiveやPigを使ってクエリをかけたり、Oozieを使ってワークフローを作成したり、クエリを開発し後で使うために保存したり、クエリの結果をUIで可視化したりできます。クラスタ上のHUE UIに繋げる方法については、こちらをクリックして下さい。Emr_hue_hive_query_cloudfront_logs_2Emr_hue_metadata_manager_3

  • Hadoop KMSでのHDFSの透過的な暗号化 - Hadoop Key Management Server (KMS)はHDFSの透過的な暗号化のための鍵を提供することができ、EMRクラスタではHDFSとともにマスターノードにインストールされています。他にもHadoop KeyProvider APIを使って外部の鍵提供システムを使うこともできます。HDFSでの暗号化はアプリケーションの読み取りと書き込みに対して透過的で、暗号化と復号はクライアントサイドで行われるので移動中もデータは暗号化されています。Amazon EMRにはクラスタ起動時に暗号化されたHDFSのディレクトリをプログラム的に作成する簡単な設定オプションも含まれています。Hadoop KMSとHDFSの透過的な暗号化についてもっと学びたい時には、こちらをクリックして下さい。

EMRサンドボックスのご紹介

EMRサンドボックスによって、完全な一般利用可能(GA)リリースにむけて開発中のアプリケーションをEMRクラスタ上で早くからアクセスすることができるようになりました。昔は、EMRで完全にサポートされていないアプリケーションをインストールするにはbootstrap actionが唯一の方法でした。しかし、bootstrap actionスクリプトを指定する必要があり、インストールはEMRのリリースと密結合しておらず、設定の管理は難しいものでした。一方、EMRサンドボックスのアプリケーションは正しくインストールされていることが証明されていて、configuration objectを使って設定でき、EMRのコンソールやCLI、EMR APIでアプリケーション名(ApplicationName-Sandbox)を使って直接指定することができます。リリース4.1.0では3つのEMRサンドボックスアプリケーションがあります:

  • Presto 0.119 - Prestoはオープンソースの分散SQLクエリ実行エンジンで、Amazon S3を含む多様なデータソースからなる大規模なデータセットに対してクエリするようにデザインされています。Prestoはインタラクティブな速さでのアドホックな分析に最適化されていて、複雑なクエリやaggregation、join、ウィンドウ関数を含むANSI SQL標準をサポートしています。PrestoはHadoop MapReduceを使わず、メモリ上でデータ処理するクエリ実行機構を持ち、ステージ毎にネットーワークを超えてパイプラインを実行します。Prestoを使うには、クラスタ上でPresto CLIを使うか、Airbnbがオープンソースにしているwebベースのクエリ実行ツールであるAirpalの様にサポートしているUIを接続します。Airpalはsyntax highlightingや結果のCSVダウンロード、クエリ履歴、クエリ保存、適切なテーブルを検索するtable finder、そしてスキーマを可視化し最初の1000行をサンプリングするtable explorerなど、いくつかのおもしろい機能を持っています。Amazon EMR上でAirpalとPrestoを使うことについては、AWS Big Data Blogの新しい投稿である”Data with Presto and Airpal on Amazon EMR”をご覧下さい。EMRでのPrestoについてのより詳しい情報は、こちらをクリックして下さい。
  • Zeppelin 0.6 (Snapshot) - ZeppelinはオープンソースのGUIで、Sparkを使ったデータ探索をインタラクティブに共同作業できるノートブックを作成します。Scala、Python、SQL (Spark SQLを使います)、またはHiveQLを使ってデータを操作し素早く結果を可視化することができます。Zeppelinのノートブックは何人かのユーザで共有することができ、可視化したものを外部のダッシュボードに公開することもできます。ノートブックでコードやクエリを実行する時に、Spark executorの動的アロケーションを有効にしてプログラム的にリソースを割当てたり、メニューの中からSparkの設定を変更(し再起動)することもできます。
  • Oozie 4.0.1 - OozieはHadoopのためのワークフロースケジューラで、有向非巡回グラフ(DAG)のアクションを作成することがdけいます。またアクションや時間で簡単にHadoopのワークフローを起動することができます。

Amazon EMRでPrestoを使っているお客様のユースケース

Prestoがサンドボックスアプリケーションとしてサポートされる前からも、特にAmazon S3上の巨大なデータセットに対するインタラクティブなアドホッククエリ用途で、多くのAWSのお客様がAmazon EMR上でPrestoを使っていました。いくつかの例がこちらになります:

  • Cogo Labsは、スタートアップのインキュベータで、マーケティング分析とビジネスインテリジェンスのプラットフォームを運用しています。Amazon EMRで動いているPrestoによって、100名以上いる開発者と分析者が500TBを超えるAmazon S3に保存されたデータにSQLクエリを実行することができ、データの探索やアドホック分析、そしてレポーティングを行っています。
  • Netflixはビッグデータに対するインタラクティブでANSI-SQL互換のクエリエンジンとして、スケールすること、オープンソースであること、そしてHive MetastoreとAmazon S3(Netflixのビッグデータウェアハウス環境の基盤)との連携を理由に、Prestoを選択しました。Netflixは常時起動のEMRクラスタでPrestoを実行していて、彼らの25PBクラスのS3のデータストアに渡って高速で柔軟なクエリを行っています。NetflixはアクティブなPrestoのコントリビュータであり、Amazon EMRによって柔軟に自前でビルドしたPrestoをAmazon EMRのクラスタ上で走らせることができています。平均的にはNetflixは3500クエリを毎日Prestoクラスタに実行しています。NetflixのPresto環境についてより詳しいことはこちらをご覧ください。
  • Jamppはモバイルアプリケーションのマーケティングプラットフォームで、広告のリターゲティング技術を使ってユーザに新しいアプリケーションを届けています。現在JamppはEMR上のPrestoで毎日40TBのデータを処理しています。
  • Kanmuは日本の金融サービス業界のスタートアップで、オファーベースの消費者クレジットカードを提供しています。Prestoはインタラクティブな速度での探索や繰り返し分析が可能で、Amazon S3でも良いパフォーマンスが出て、巨大なデータにもクエリできるスケーラビリティがあることから、KanmuではHiveからAmazon EMR上のPrestoに移行しました。
  • OpenSpanは人や処理や技術を橋渡しして、従業員の生産性や取引の単純化、そして従業員と顧客の愛着を増やすための洞察を得る手助けを自動でしてくれる頭の良いソリューションを提供しています。OpenSpanはHBaseから、Amazon S3をデータレイヤーにしたAmazon EMR上のPrestoに移行しました。ANSI SQLのインタフェースを持ち、Amazon S3にリアルタイムに直接クエリを実行できるため、大量のデータを素早く探索して次々にやってくるデータを高速に処理することが可能になるという理由からOpenSpanはPrestoを選択しました。

インテリジェントなリサイズ機能

リリース4.1.0で、我々はインテリジェントなリサイズ機能を追加しましたので、実行中のジョブに対する影響を最小にしてEMRクラスタを縮退することができます。加えて、クラスタにインスタンスを追加するときにも、利用可能になったらすぐにそのキャパシティを使いはじめることができるようになりました。以前は、全てのリクエストしたキャパシティが利用可能になるまで、YARNが追加したノードにタスクを送ることができませんでした。また、現在(クラスタの目標サイズを変更するための)リサイズのリクエストが実行されている間でもリサイズのリクエストやリサイズ処理を停止することもできるようになりました。

Emr_resize_up_1

クラスタのサイズを減らすときには、プログラム的にタスクが実行されていないインスタンスを選ぶか、もしクラスタの全てのインスタンスが利用中であれば、あるインスタンスがタスクを完了するまでクラスタからの削除を待ちます。デフォルトの待ち時間は1時間で、この値は変更可能です。また/home/hadoop/conf/yarn-site.xmlか/etc/hadoop/conf/yarn-site.xmlのyarn.resourcemanager.decommisioning.parameterを変更することでタイムアウトの秒数を指定することもできます。EMRは動的に新しい設定へ更新し、resourse managerの再起動は必要ありません。これを任意の大きな数字にすることで、クラスタを縮小する際にどのタスクもkillされないことを保証できるようになります。

Emr_resize_down_2

加えて、Amazon EMRは、実行中のYARMコンポーネントによってHDFSの一部データを保持しているcore groupからのインスタンス削除をサポートするようになります。退役処理の間、クラスタに必要なreplication factor(EMRはデフォルトではreplication factorを1-3 core nodesなら1、4-9 core nodesなら2、10以上のcore nodesなら3としています)を満たす様にHDFSはそのインスタンス上のブロックを他のアクティブなインスタンスに複製します。データロスを防ぐために、EMRはHDFSがデータ保存のために要求するストレージの要件を下回る様なクラスタの縮小は許可しませんし、退役するインスタンスから残りのインスタンスにブロックの複製が成功するだけの十分な空き容量がクラスタにあることを保証します。もし要求したインスタンスの数が既存のHDFSのデータに対して小さすぎた場合、いくつかのインスタンスだけが退役させられます。

core groupからnodeを削除する前にHDFSへの重い書き込みを最小化することをオススメします。書き込み中のブロックやレプリカブロックの不整合によってHDFSのレプリケーションは遅くなる可能性があり、それはリサイズ処理全体のパフォーマンスを低下させます。EMRクラスタのリサイズについてはこちらをクリックして下さい。

Emr_core_resize_down_2

Amazon EMRクラスタ 4.1.0は今日から使えます

EMRクラスタを4.1.0で作成するには、AWSマネジメントコンソールのクラスタ作成ページ上でリリース4.1.0を選ぶか、AWS CLIかEMR APIを通じたSDKを使う場合にはrelease labelに”emr-4.1.0”を使います。

-- Jon Fritz and Abhishek Sinha

原文: https://aws.amazon.com/jp/blogs/aws/amazon-emr-release-4-1-0-spark-1-5-0-hue-3-7-1-hdfs-encryption-presto-oozie-zeppelin-improved-resizing/ (翻訳: SA岩永)

Viewing all 446 articles
Browse latest View live