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

Zocaloのアップデート - MFA、ファイル共有リンク、ファイルの移動、フィードバックの辞退

$
0
0

今や私は熱心なAmazon Zocaloユーザーです!私は、ブログ記事や翻訳記事やセミナー資料を、社内関係者に共有し、フィードバックやコメントを受け付けるという使い方をしています。Zocaloが提供するフルマネージドで簡単なファイルの共有とフィードバックの仕組みはとても有り難いものです。

本日、Zocaloの便利な新機能を発表いたしました!

多要素認証(MFA) / RADIUSのサポ-ト
新たにRADIUSサーバーを使った多要素認証(Multi-Factor Authentication, MFA)をサポートしました。これにより、ユーザー認証のセキュリティをさらに強化することが可能になります。多要素認証を有効にすると、ログイン時にユーザ名とパスワードに加えて、ハードウェアまたはソフトウェアによって提供されるワンタイムパスワード(OTP)を入力する事が求められるようになります。

Zocaloサイトの管理者はManagement Consoleを使ってMFAおよび接続先のRADIUSサーバの設定を行うことができます。設定を開始するにはActionsメニューからManage MFAを選択してください。

Zocalo_manage_mfa_menu_1

MFAの設定は全てこのページで行います。

Zocalo_manage_mfa_1

 

ファイル共有リンク
リンクURLを生成してファイルを共有できるようになりました。共有先の相手は既にZocaloサイトのユーザーである必要があります。

Zocalo_share_dialog_1

 

フィードバックの辞退
Zocaloで要求されたフィードバックを辞退することができるようになりました。忙しくて時間が取れない場合や、特にコメントすべき事項が無い場合はアクションバーからフィードバックリクエストを辞退しましょう。

Zocalo_decline_feedback_1

 

ファイルの移動
ZocaloのWebインタフェースを使って、ファイルやフォルダを移動することができるようになりました。ファイルを選択すると表示されるアクションバーに、新たにMove...オプションが表示されるようになっています。

Zocalo_sharing_1

 

いますぐお試しください!
Zocaloは30日間無料でご利用頂けます。無料トライアルでは最大50名までのユーザー毎に200GBのストレージが提供されます。

 

小林


Route53のアップデート - プライベートDNS、他

$
0
0

Amazon Route 53 は、高可用性とスケーラビリティを有したDNSサービスです。ご存知かと思いますが、Route 53はドメイン名をIPアドレスに変換します。これによって、コンピュータをIPアドレスのかわりに、おぼえやすい名前で参照することができます。IPアドレスが変わっても、名前はずっと同じものを使うことができます。

これまでRoute 53はグローバルでパブリックな名前の解決に主に使われてきました。Amazon Virtual Private Cloud (VPC) 内部システムのために使うこともできましたが、VPC内部でしか使っていないIPアドレスであっても名前はグローバルから見える形でした。

本日、Route 53のプライベートDNS機能を発表しました。これを使えばVPC内で権威DNSを管理するのが簡単にできます。パブリックなインターネットに名前やIPアドレスを見せずに内部のリソースにカスタムDNS名を使うことができます。

本日のローンチでは、AWS Management Consoleも、ヘルスチェックに失敗したときの追加情報を扱えるように、アップグレードしました。さらに、delegation setが再利用可能になり、複数のドメインをRoute 53で管理するのがよりシンプルになりました。

それでは、これらの機能をそれぞれ見て行きましょう!

プライベートDNS

Route 53を内部のアプリケーションリソース(Webサーバ、アプリケーションサーバ、データベース等)に対して、内部用のDNS名をつけて管理するために使うことができます。もちろん情報は外部にさらされることはありません。これによって、セキュリティレイヤを1段加えることになります。また、プライマリリソースから、セカンダリリソースへの切り替えをホスト名に紐付いたIPアドレスの切り替えも可能です。

Route 53はスプリットDNS(Split-horizon DNS)も実現できます。これはあるリソースのDNS名をVPC内部から参照したときと、外部から参照したときに、別のIPアドレスを答えさせる方法です。

Route 53のプライベートDNS機能を使うには、Private Hosted Zoneオプションを選択し、VPCを指定して作成します。

コンソールにはそれぞれのhosted zoneが表示されます。

詳しくは、Working with Private Hosted Zonesをご覧ください。

再利用可能なDelegation Set

Route 53をあるドメインのホストのために使うと、Delegation setとして4つの権威ネームサーバが選ばれます。本日のリリースで、ドメイン管理をシンプルにするために同一のDelegation setを複数のドメインで共用することができるようになりました。これは上級者向けのAPIのみで使える機能ですが、いくつかの方法で使うことができます。

  • 多くのドメインをまとめて他のプロバイダからRoute 53に移動させるときに、それらのドメインには全て同じ4つのネームサーバを使わせることができます。
  • 例えば、ns1.example.comとns2.example.comといったホワイトレーベルのネームサーバをつくれます。それらはRoute 53のネームサーバを指すことになります。

詳しくは、APIドキュメントのActions on Reusable Delegation Setsをご覧ください。

ヘルスチェック失敗の理由の取得 

昨年、Route 53のヘルスチェック機能を追加しました。また、ヘルスチェックのタグ編集機能もリリースしています。本日は、この機能をさらに拡張し、それぞれのヘルスチェック結果をコンソールとAPIから取得できるようになりました。コンソールには次のように表示されます。

注意:ヘルスチェックはVPCのプライベートサブネット内では動作しません。同様に、Route 53 プライベートDNSレコードでは、ヘルスチェックは有効にできません。

試してみましょう

これらの機能は、今日からお使いいただけます。

-- Jeff; (日本語版は荒木が担当しました)

Amazon DynamoDB:  前回紹介しきれなかったアップデート

$
0
0

先日のブログポストで紹介したとおり、JSONサポート、アイテムあたりの最大サイズの引き上げ(64KB->400KB)、無料枠の拡大(月あたり25GBのストレージと2億リクエスト)など、DynamoDBには非常に多くのアップデートがありました。しかし、それでもまだ紹介しきれていない項目があるので、今日はそれらについて語りたいと思います。

  • DynamoDB JavaScript Web Shell - DynamoDB LocalにWeb画面でアクセスできるシェルが組み込まれました。簡単に使いはじめるためのチュートリアルも含まれています。

  • SQL-Like Expressions - このSQLのように書けるExpressionは、NoSQLデータベースのAPIをより使いやすくしてくれて、更にコードの可読性を挙げてくれることでしょう。

  • より洗練された各種条件付け・フィルタリング - この強力であたらしいサーバーサイドフィルタリングはクライアントへの無駄なデータ転送を減らし処理を効率化してくれます。さらにConditional Writeのオーバーヘッドも削減してくれるでしょう。

JavaScript Web Shell

DynamoDB Localにあたらしく、DynamoDB JavaScript Shell(以下、Web Shell)という名のウェブベースのユーザーインターフェイスが追加されました。使い始めるのは簡単です。DynamoDB Localのアーカイブファイルをダウンロードし、それを好きな場所に展開してください。そして以下のようなコマンドで起動します。

C:\temp\L> java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar

Web Shellはポート8000番の/shellというURLでアクセスできます。(ポート番号は変更可能です)

Web Shell1

Web Shellの見た目はこのような形です。左側がコードエディタ、右側がコンソールです。

Web Shell2

JavaScriptのコードをエディタで作成し、Runボタンを押して実行します。例えば下のスクリーンショットはテーブルの作成をしているところです。

Web Shell3

このシェルにはDynamoDBの各APIを呼び出すためのコードテンプレートが含まれています。”>”というボタンからテンプレートを呼び出し、任意のコードを”<<”でコードエディタにコピーすることができます。また、コードエディタ内でControl + Spaceでコード補完を呼び出すこともできます。

Web Shell4

例えば下記のようなAWS SDK for JavaScript in the Browserを使ってテーブルを作成するコードを生成し、実行することが非常に簡単にできます。

var params = {
    TableName: 'book',
    KeySchema: [
        {
            AttributeName: 'title',
            KeyType: 'HASH',
        }
    ],
    AttributeDefinitions: [
        {
            AttributeName: 'title',
            AttributeType: 'S'
        }
    ],
    ProvisionedThroughput: {
        ReadCapacityUnits: 1,
        WriteCapacityUnits: 1,
    }
};
dynamodb.createTable(params, function(err, data) {
    if (err) print(err); // an error occurred 
    else print(data); // successful response 
});

テーブルにアイテムを挿入することも非常に簡単です。

var params = {
    TableName: 'book',
    Item: { // a map of attribute name to AttributeValue 
        title: "Sample Application: CloudList",
        chapter: 10
    }
};
 
dynamodb.putItem(params, function(err, data) {
    if (err) print(err); // an error occurred 
    else print(data); // successful response 
});

テーブルをScanすることも簡単です。下記はScanの最初の1ページの結果を受け取るコードのサンプルです。

var params = {
    TableName: 'book',
};
dynamodb.scan(params, function(err, data) {
    if (err) print(err); // an error occurred 
    else print(data); // successful response 
});

上記のコードをWeb Shellで実行するとこんなイメージになります。

Web Shell 5

ここまで紹介してきたWeb ShellはDynamoDB Localの一機能として提供されているので、何も新しいセットアップをせずに利用することができます!

SQL-Like Expressions

更に今回、DynamoDBのScanやQueryといったAPIが、よりシンプルでSQLに近いクエリ言語を受け付けるようになりました。たとえば"long.example.com/"から始まっていて、なおかつ"2014-09"以降に作成されたアイテムをScanで取得するなら以下のように実装することができます。

dynamodb.scan({
    TableName: 'Url',
    ProjectionExpression: 'ShortUrl, RedirectTo, Metadata.CreatedBy',
    FilterExpression:
      'begins_with(RedirectTo, :domain) ' +
      'AND Metadata.CreateDate >= :start_date',
    ExpressionAttributeValues: {
        ':domain': 'long.example.com/',
        ':start_date': '2014-09'
    }
}).eachPage(function(err, data) {
    if (err) print(err);
    else if (data) print(data);
});

より洗練された各種条件付け・フィルタリング

今年の前半、ScanやQuery、Conditional Writeのためのフィルタがリリースされました。今回のアップデートでは更に、ネストされたANDやOR、NOTなどの条件を備えた、よりSQLのWHERE句に近い操作を実行することが可能になりました。これにより、たとえば同じアトリビュートを条件内で何度も指定したり、既存のアトリビュートを比較したりすることもできるようになりました。(これらはいままでのAPIでは実現できませんでした。)

たとえば下記のJavaScriptのスニペットは”Short URL”テーブル(短縮URLサービスを実現するためのテーブルをイメージしてください)をScanします。この操作に対してExpressionを活用し、予め定められたページビュー数に達しておりかつ、"map"というタグを付与されているもしくは"long.example.com"というドメインに紐付けられている、という検索条件を付与しています。

dynamodb.scan({
  TableName: 'Url',
  FilterExpression:
    "(contains(Tags, :tag)) " +
     "OR begins_with(RedirectTo, :domain)) " +
    " AND " +
    "Stats.PageViews > Metadata.TargetViews",
  ExpressionAttributeValues: {
    ":tag": "map",
    ":domain": "long.example.com"
  }
}).eachPage(function(err, data) {
  if (err) print(err);
  else if (data) print(data);
});
 
 
今井

Amazon WorkSpacesのアップデート - バリューバンドル、ハードウェアのアップグレード、そしてOffice 2013

$
0
0

Amazon WorkSpacesの管理者とユーザーのみなさんにいいお知らせがあります。あたらしいバリューバンドルと、既存のスタンダードバンドルのアップグレード、そしてOffice 2013がプラスバンドルで利用可能になったことをご紹介します。これは多要素認証(MFA)、ゼロクライアントのサポート、そして ゴールデンイメージの作成など一連の機能追加の中でも最新のものとなります。

バリューバンドル

バリューバンドルはブラウザとひとつかふたつのアプリケーションを動かすような、ライトユーザー向けに用意されています。バリューバンドルは1vCPU、2GBメモリ、そして10GBのユーザーストレージで1ユーザーあたり$25の費用になります。バリュープラスバンドルは同じハードウェアスペックでMicrosoft Office Professionalが利用できます。費用は1ユーザーあたり$40(これらの価格はUS East (北バージニア)とUS West (オレゴン)リージョンのもの)です。その他のリージョンでの価格についてはWorkSpaces料金表のページを参照してください。

スタンダードバンドルのアップグレード

スタンダードバンドルのアップグレードによって、追加の費用なしでハードウェアリソースの増強が行われました。2014年末までに、スタンダードバンドルを利用している既存のWorkSpacesはすべて1vCPUから2vCPUに、メモリが3.75GBから4GBにアップグレードされます。このアップグレードはWorkSpacesを利用しているAWSリージョンごとに決められたメンテナンスウィンドウの中で行われます(5日前には事前に通知されます)。CPUのキャパシティが倍になってメモリが追加されますので、明らかに体感パフォーマンスが向上するでしょう。

このアップデートはWorkSpaceのC:D:ドライブ上にあるユーザーデータにはまったく影響ありません。ユーザーはデスクトップのメンテナンスウィンドウが完了した月曜の朝にログオンするとWorkSpaceが再起動されてパフォーマンスが向上しているということになります。

Office 2013

3つすべての「プラス」バンドル(バリュー、スタンダード、パフォーマンス)にはMicrosoft Officeがふくまれていますが、新規にWorkSpacesを作成するときにOffice 2010とOffice 2013のいずれかを選べるようになりました。Office 2010を利用している既存のWorkSpacesは、Office 2013にアップグレードすることができます。

利用可能なリージョン

あたらしいバンドルは今日からUS East (北バージニア)、US West (オレゴン)、  ヨーロッパ (アイルランド) とアジアパシフィック(シドニー)リージョンで利用できます。アジアパシフィック (東京)リージョンでは近日中に利用可能になる予定です。 

渡邉

CloudFront アップデート - よりタイムリーなログ保管、キャッシュ統計、人気オブジェクトレポート

$
0
0

Amazon CloudFront チームは分析やレポーティングの機能を今年たくさん追加してきました。最近のリリースを振り返ってから、今回のリリース内容を紹介します。おそらく皆様ご存知と思いますが、CloudFront はAWS の他のサービスと統合されたコンテンツ配信のWebサービスで、エンドユーザは簡単に効率的な低遅延のコンテンツ配信を行うことが出来ます。

使用状況グラフ

3月には、CloudFront の使用状況グラフをリリースしました。グラフで CloudFront のディストリビューションごとのデータ転送やリクエスト数(HTTPとHTTPS両方)の傾向を確認できます。データは1日あるいは1時間の粒度で表示されます。これらの表は追加の費用無しでご利用いただけます。データを収集して表を表示させるためにディストリビューションの設定変更は不要です。以下は、ある私のディストリビューションのグラフです。:

確認したいディストリビューション、期間、粒度を簡単に選択できます。:

また課金対象のリージョンで絞り込むこともできます。:

メトリックス

先月 CloudFront は Amazon CloudWatch に便利なメトリックスの送信を始めました。これらのメトリックスは1分毎に送信され、数分前の状況が反映されます。これによりほとんどリアルタイムの情報を提供できるようになりました。他のどんな CloudWatch メトリックスと同様に、全ての項目は表示したりアラームを設定することができます。以下のメトリックスがディストリビューション毎に利用できます。:

  • Requests - 全 HTTP メソッドの HTTP と HTTPS 両方のリクエスト回数。
  • BytesDownloaded - ユーザから GET, HEAD, OPTIONS リクエストでダウンロードされたバイト数。
  • BytesUploaded - POST や PUT リクエストで CloudFront を通じてオリジンにアップロードされたバイト数。
  • TotalErrorRate - 全リクエスト中 HTTP ステータスコードが 4xx あるいは 5xx であるパーセンテージ。
  • 4xxErrorRate - 全リクエスト中 HTTP ステータスコードが 4xx であるパーセンテージ。
  • 5xxErrorRate - 全リクエスト中 HTTP ステータスコードが 5xx であるパーセンテージ。

最初の3つのメトリックスは絶対値で、統計を Sum にして見ることがほとんどん場合に適切です。例えば、以下はある私のディストリビューションでの時間ごとのリクエストレートです。

他の3つのメトリックスはパーセンテージで、Average での表示が適しています。以下は私のディストリビューションのエラーレートです(なぜエラーレートが高いのかわからないため、少し時間をかけて調べる必要があります)。

このエラーを監視できるように、以下の通りアラームを設定します。

メトリックスは常に米国東部(バージニア)リージョンに配置されます。コンソールのドロップダウンメニューでリージョン選択を確認して下さい。ディストリビューションにこれまでトラフィックが無かった場合、メトリックスは作成されません。そのためリクエストが無ければ CloudWatch にメトリックスは表示されません。

New - よりタイムリーなログ保管

CloudFront のログが保管されるタイミングを改善しました。2つの側面で改善があります。1つ目は、CloudFront が Amazon Simple Storage Service (S3) のバケットに保管される頻度を上げました。2つ目は、データを集めてからデータを保管するまでの間の遅延を削減しました。これからの改善により、バケット内にある最新のログファイルはつい1時間前起こったイベントが反映されるようになります。

今回のリリースの一部としてバッチ処理のモデルも改善しました。この結果、これまでより保存頻度が上がったにも関わらず、保存されるファイル数が減りました。

New - キャッシュ統計 と 人気オブジェクトのレポート

キャッシュ統計レポートを新たにリリースしました。レポートはログファイル内のエントリに基づいており、ディストリビューション毎や全ディストリビューションで確認ができ、60日間の間で好きな期間を1日の粒度で表示させたり、同じ60日間の14日について1時間の粒度で表示させることができます。これらのレポートはユーザの地域でフィルタリングすることができます。例えば、ユーザの地理的な地域に応じたトラフィックの特性をより理解するために、大陸ごとにフィルタリングすることができます。

以下のレポートが利用できます。:

  • Total Requests - このレポートは全てのメソッド、全てのHTTPステータスコードでの合計リクエスト数を示しています。
  • Percentage of Viewer Requests by Result Type - このレポートはユーザからの全リクエスト中のキャッシュヒット、ミス、エラーのパーセンテージを示しています。
  • Bytes Transferred to Viewers - このレポートは全てのHTTPメソッド、全てのリクエストにおけるレスポンスで CloudFront がユーザに送信したバイト数を示しています。また、エッジキャッシュ(CloudFront のノード)に無かったオブジェクトをユーザに送信した合計バイト数も示しています。これはオリジンからのデータ転送量のよい近似値です。
  • HTTP Status Codes - このレポートはユーザからのリクエストに対するHTTPステータスコード(2xx, 3xx, 4xx, and 5xx)の回数を示しています。
  • Unfinished GET Requests - このレポートは全リクエスト中におけるダウンロードが完了しなかったGETリクエストのパーセンテージを示しています。

レポートは以下の通りです。:

新しい人気オブジェクトのレポートは、指定した期間における上位50位の人気オブジェクトについてリクエスト回数、キャッシュヒット回数、キャッシュミス回数、エラーレートを示しています。これはユーザにどのコンテンツが人気があるかを理解したり、よくリクエストされるオブジェクトについての問題(例えばエラーレートが高いなど)を見つけるのに役立ちます。以下は、ある私のディストリビューションのレポートです。:

今すぐご利用いただけます

新しいレポートやよりタイムリーなログ保管は既にご利用頂けるようになっています。

新しい認定プログラム、DevOpsエンジニア

$
0
0

本日は新しいAWS認定プログラムである AWS認定DevOpsエンジニア - プロフェッショナルを紹介します。皆様もご存知の通りだと思いますが、DevOpsのロールは皆様のビジネスに対するIT効率を高め、安定し、セキュアで、予測可能なIT環境を提供することにより、お客様へのより迅速な対応を可能にします。クラウドコンピューティングが主流になっていくにつれて、このロールが生み出す利益に着目し、DevOpsの技術に対する需要は高まっています。この認定プログラムは、ITプロフェッショナルがDevOpsの領域にいる人々の技術を認定するのに役立ち、DevOpsを率先して進める有能な方を組織として確認/発見することを可能にします。

もし今週、AWS re:Inventに参加されるなら、この認定試験を一番に受けることができます!また、 re:Inventでは認定試験に関する様々なアクティビティーをご用意してます。

DevOpsエンジニアのための新しいAWS認定プログラム
AWS認定DevOpsエンジニア - プロフェッショナルは、AWS認定デベロッパーとAWS認定SysOpsアドミニストレーターの上位認定です。 この試験は、AWSプラットフォーム上の分散アプリケーションシステムのプロビジョニング、運用、管理における技術的な知識を保有している事を証明するものです。これは、AWSプラットフォーム上で高い可用性を持ち、スケーラブルで、自己回復できるシステムを導入、管理できる人々を証明するように設計されています。

前提資格として、AWS認定デベロッパー - アソシエイト、もしくは、 AWS認定SysOpsアドミニストレーター - アソシエイトを保有している必要があります。また、数年間にわたりAWS環境をプロビジョニング、運用、管理した経験があること、それに加えて、少なくとも1つの高レベルプラグラミング言語を使ったコードを書いた経験、スクリプトやプログラムを通して、自動化と試験を完遂した経験をもっている必要があります。さらに、アジャイルやその他の新しい開発プロセスや手法を理解している必要があります。

ベータ試験は、次週、re:Invent 2014 で開始され、12月中旬まで行われる予定です。この試験に関する詳細と参考資料(試験ガイドとサンプル問題)をAWS認定プログラムのページから入手することが出来ます。(現時点では、英語のみの提供となります。)

re:Invent便り
AWS re:Inventに参加する予定であれば、オンラインで試験予約が可能で、re:inventで、試験に合格しませんか?また、11/13(木)午後5:30-7:00にPublic Houseで行われるAWS認定プログラムレセプションを行います。認定者とのネットワーキングパーティーであり、もしかするとAWSエグゼクティブ会うことが出来るかもしれません!

 

杉村/江川

あたらしいMicrosoft System Center Virtual Machine Managerアドイン

$
0
0

多くのエンタープライズクラスのAWSのお客様がオンプレミスに大規模な仮想化されたWindowsサーバーを持っています。これらのお客様はあらゆるワークロードをクラウドに移行しつつありますが、オンプレミスとクラウドベースのシステム管理のニーズを満たすための統一された手段が必要となっています。複数のツールを利用して同じような基本的な作業(監視、および仮想サーバーもしくはインスタンスの操作)を実行するのは非効率的なため、オンプレミスとクラウドのリソースを組み合わせたソリューションの開発は複雑になりがちです。

あたらしいアドイン

こういった重要なお客様に対してリソースを管理するためのより効率的な方法を提供するため、 AWS System Manager for Microsoft System Center Virtual Machine Manager(SCVMM)をローンチしました。このアドインはMicrosoft System Center Virtual Machine ManagerからAmazon Elastic Compute Cloud(EC2)インスタンス(WindowsとLinuxどちらでも)の監視と管理ができるようにするものです。このアドインをつかってインスタンスの再起動、停止、さらに削除などの一般的なメンテナンス作業をおこなうことができます。また、Remote Desktop Protocol(RDP)を利用してインスタンスに接続することができます。

このアドインをさっとみていきましょう!こちらがメイン画面になります:

 パブリックなAWSリージョンであればどれでも選択できます:

WindowsのEC2インスタンスを起動した後、アドインをつかってAdministratorパスワードの取得、復号化と表示が可能です:

 複数のインスタンスを選択してグループとして操作することができます:

いますぐ利用できます

このアドインは追加コストなしでいますぐにダウンロード可能になっています。ダウンロードしてインストールした後、IAMのクレデンシャルを入力するだけで利用できます。クレデンシャルはローカルのコンピュータにログインしているWindowsユーザーに関連付けられるため入力するのは一度だけです。

すべてのAWSプロダクトについてそうなのですが、あなたのフィードバックをドキドキしながらおまちしております(機能リクエスト、バグレポート、その他思いついたらなんでも)。scvmm-info@amazon.comまでご連絡ください。

渡邉

Amazon RDS for PostgreSQLのアップデート- リードレプリカ、9.3.5のサポート、データ移行、3つの新しい拡張モジュール

$
0
0

本日は、Amazon Relational Database ServiceチームのSrikanth Deshpandeが、Amazon RDS for PostgreSQLに追加されたリードレプリカ、データ移行機能のアップデート、3つの拡張モジュールなどの最新かつすばらしい機能を紹介します。

-- Jeff(翻訳版は江川が担当しました)


リードレプリカ
このたび、Amazon RDS for PostgreSQLは、需要が高いRDS機能であるリードレプリカをサポートします。この機能により、参照比率が高く、高トラフィックを誇るウェブ、モバイルアプリケーションの要件を満たすべく、PostgreSQLを使用するお客様が簡単にデータベースをスケールアウトすることができます。

この機能により、PostgreSQLデータベースインスタンスの複数のコピー、いわゆる、レプリカを作成でき、参照トラフィックをそのレプリカに分散させることにより、アプリケーションをスケールさせることができます。 リードレプリカ作成後、このレプリカは、PostgreSQLの非同期ストリーミングレプリケーションを使用して、同期し続けます。 また、AWS マネジメントコンソールAWS コマンドラインインターフェイス (CLI)、RDSのAPIを使用して、数分でレプリカの作成や削除が容易にできます。 一度レプリカを作成すると、PostgreSQLの非同期ストリーミングレプリケーションを使用して、データをコピーし続けます(非同期であるため、場合によっては、マスタへの書き込み後、リードレプリカへの反映までにタイムラグが発生する可能性があります)。Amazon RDSはレプリカに反映するまでのライムラグを監視する機能を提供するので、必要に応じでアプリケーションを調整することができます。リードレプリカは、Multi-AZと併せて使用できます。これにより、参照スケーラビリティの利点とMulti-AZデプロイメントによる耐障害性、可用性の利点を同時に享受できます。

リードレプリカを作成するには、マネジメントコンソールから更新を行うマスタを選択し、[Instance Actions]のメニューから[Create Read Replica]をクリックします。

詳細を入力し、[Create Read Replica]ボタンをクリックします。

現在使用しているインスタンスで、リードレプリカを使用するためには、PostgreSQLのバージョンを9.3.5にアップグレードする必要があります。幸運なことに、AWS マネジメントコンソール、APIを使用して、数分でアップグレードできます。それから、スケールアウトが可能です。PostgreSQL9.3.5とともに、PostGISのバージョンも2.1.3へアップグレードされます。

お客様の声
お客様がどのようにAmazon RDS for PostgreSQLを利用しているかをより理解するため、そして、リードレプリカをどのように使うつもりか感触を伺うため、2社のお客様に対してインタビューを行いました。

Flipagramは、iOSのAppストアとGoogle Playにて、トップ100のモバイルアプリに選ばれました。彼らは、ユーザーに対して、写真を使ったビデオ動画の作成や共有ができるプラットフォームを提供しています。創設者かつCTOのBrian Dilleyにインタビューしました。以下は、彼が私に話したことです。

私たちが、RDS PostgreSQLを使い始め、それをスケールアップさせてきたのは、非常に小さいチームで、RDS PostgreSQLの管理業務やコンピュート、ストレージ、I/Oスケーラビリティーをレバレッジさせることにより、多くのユーザーからの負荷を支えるためです。 私たちは、可用性を高めるためにMulti-AZを使い、マネジメントコンソール上でチェックボックスをオンにするだけで、商用ワークロードに高可用性を持たせることができる能力を愛しています。私たちは、商用環境、検証環境、テスト/開発環境のすべてでRDS PostgreSQLを実行しています。2013年12月、80か国のAppストアでNo.1になったとき、非常に大きなスパイクが発生するトラフィックに対応するために、RDSを使用し、ワンクリックでインフラストラクチャをスケールさせることで乗り切れました。私たちがユーザーに対して素敵な体験をしてもらうことにフォーカスする限り、サービスが成長するにつれて大きくなる参照トラフィックにあわせてスケールするようにリードレプリカを使うのが楽しみになってきます。

E la Carteは、サービス開始以来、Amazon RDS for PostgreSQLを使い続けています。彼らのPrestoタブレットは、スマートデザイン時代の到来を示しています。 Bill Healey (E la CarteのCTO)は次のように語ってくれました。

RDS Postgresを使用するまで、非常に大きなエンジニアリングリソースが必要になるPostgreSQLインスタンスを自分たちで管理してきました。しかし、RDSにより、速く、容易に、レプリケーションさせ、データベースサイズ、IOPSともにスケールアップさせることができるようになりました。私たちは、ずっとRDS Postgresにリードレプリカ機能が追加されることを楽しみにしていました。E la Carteは、まさにデータドリブンで、常に商用DBのデータから直接データ解析しつつ、データウェアハウスによる集積データの解析を行っています。私たちは、データウェアハウスのETLツールとデータ解析ツールの性能を高めて、RDS商用インスタンスへの負荷を下げるために、RDSリードレプリカを使うことを楽しみにしています。

トリガーベースのレプリケーション
このたび、RDS PostgreSQLは、レプリケーション権限をサポートします。 RDSでは、この権限をLondisteBucardoのようなオープンソースのトリガベースツールと併せて使用することができます。これらは、わずかなダウンタイムでRDS for PostgreSQLの外部へ、もしくは外部から既存のデータを移行するために利用できます。

データインポート(Londiste)
Londisteを使ってデータをインポートするためには、(RDSではない)外部のPostgreSQLインスタンスにそれをインストールし、RDS PostgreSQLインスタンスをレプリカとしてセットアップし、レプリケーション権限を有効にする必要があります。 Londisteは始めに既存のデータベースからデータをダンプし、RDSのPostgreSQLインスタンスにデータをロードします。これは、外部のPostgreSQLインスタンスが更新トラフィックを受付ながら実行されます。それが終わった後、RDSインスタンスは、その間に外部DBで行われていた更新に追いついていくでしょう。一度、RDSインスタンスが既存のデータベースと同じ状態になれば、ダウンタイムが最小になる時間を選んで、実行しているアプリケーションのアクセス先をRDS PostgreSQLインスタンスにすることができます。

データエクスポート(Bucardo)
また、レプリケーション権限をRDS for PostgreSQLインスタンスからオンプレミスやEC2上の外部のPostgreSQLへのデータエクスポートするためにも使用できます。これを実現するには様々な方法があります。たとえば、トリガーベースの楽観的レプリケーションを実現するオープンソースソリューションであるBucardoを外部のインスタンスにインストールし、RDS PostgreSQLをマスターインスタンスとするレプリケーションのスレーブとしてセットアップできます。Bucardoは、外部のインスタンスがオンラインである限り、RDSインスタンスにあるデータを外部のインスタンスに複製します。楽観的レプリケーションであるため、外部のインスタンスがオフラインになり、オンラインに戻ったとしても、Bucardoは、外部のインスタンスが結果的に整合性をとることを保証します。

新しい拡張モジュール
リードレプリカ、PostgreSQL 9.3.5のサポート、トリガベースのレプリケーションに加えて、需要が高い3つのPostgreSQL拡張モジュールをサポートします。

  • pg_stat_statements - pg_stat_statementsは、SQL文を実行したuserid、SQL文の文字列、SQL文の処理に費やした総時間などのインスタンスで実行されたすべてのSQL文の実行時の統計情報を記録する手段を提供します。
  • postgres_fdw - postgres_fdwは、他のRDS PostgreSQLインスタンスにあるテーブルのような外部のPostgreSQLサーバーにあるデータの参照、更新を行う機能を提供します。
  • PL/V8 - これは、V8 JavaScriptエンジンが組み込まれたPostgreSQLの手続き言語の外部モジュールです。この拡張モジュールによって、SQLから呼び出せるJavaScriptの関数を書くことができます。

これらの拡張モジュールを利用するには、AWSマネジメントコンソールやAPIを使って、新しいインスタンスを作成するか、既存のインスタンスをアップグレードする必要があります。

Amazon RDS for PostgreSQLのページには、これらの新機能を使うために必要な技術情報、料金に関わる情報が記載されています。

-- Srikanth Deshpande, Amazon RDS シニアプロダクトマネージャー -- 江川


Amazon ElastiCache for RedisのMulti-AZサポート / 自動フェールオーバー

$
0
0

他の AWS と同様、 Amazon ElastiCache は最初にシンプルにスタートし、徐々に機能拡張をしてきました。 以下、最も重要なマイルストーンの振返りになります:

  • August 2011 - 初期リリースでMemcachedを1つのリージョンでサポート。
  • December 2011 - 4つのリージョンに拡張。
  • March 2012 - 一つ目の値下げを実施。
  • April 2012 - リザーブドインスタンス対応。
  • November 2012 - 更に4つのインスタンスタイプを対応。
  • September 2013 - Redisキャッシュエンジンのサポート。レプリカを用いたレプリケーション グループ機能で読込スループットの向上。
  • March 2014 - 2度目の値下げ。
  • April 2014 - Redisクラスタのバックアップやリストア機能追加。
  • July 2014 - M3やR3キャッシュノードのサポート。
  • July 2014 - 同一リージョン内のAZを跨いだノード置換え。
  • September 2014 - T2キャッシュノードのサポート。

 

AWSサービスをご利用の際、そのサービスが常に機能を拡張し続けることを経験されるはずです。 上記リストのとおり、一部の機能拡張はアーキテクチャ、スケールやロケーションにおいてより柔軟な選択肢を提供します。ほかの拡張、例えば値下げやリザーブドインスタンス対応、は利用者のコスト削減に貢献します。 また、可用性や耐障害性の高いアプリを簡単に構築できるように拡張した機能もあります。

RedisのMulti-AZサポート

今回のリリースは、Redisキャッシュクラスタの可用性や耐障害を向上させる機能になります。複数のAZを跨ぐ(Multi-AZ)レプリケーション グループを作成し、自動フェールオーバーを可能にします。Multi-AZ構成のレプリケーション グループを作成したあと、ElastiCacheはノードのヘルシー状況や接続可能かをモニターします。もしプライマリノードがダウンした場合、ElastiCacheは最も低いレプリケーション ラグ(つまり最新データ)を持つリードレプリカを選んでプライマリに昇格させます。その後、DNS変更を行い、もう1つのリードレプリカを作成し、クラスタを通常状態に復旧させます。利用者側で特に管理作業が必要ありません。

この新しい自動フェールオーバーとリカバリ機能はRedisキャッシュクラスタの可用性を高めます。下記状況においてフェールオーバーが発生します:

  1. プライマリがあるAZがダウンした場合
  2. プライマリへのネットワーク接続ができなくなった場合
  3. プライマリがダウンした場合 

Multi-AZ レプリケーション グループの作成
Multi-AZキャッシュ レプリケーション グループを作成するため、Create Cache Clusterを選んだあとに、Multi-AZ チェックボックスをチェックします: 

初期値としてデフォルトのAZはアサインされます。また、アプリの要件に合わせて調整も可能です:

Multi-AZ for Existing Cache Clusters

既存のキャッシュクラスタを変更し、数クリックだけでMulti-AZ構成や自動フェールオーバーを有効することも可能です。

Things to Know

ElastiCache for RedisのMulti-AZサポートは、新しいRedis(2.8.6またはそれ以降)の非同期レプリケーションを利用しています。そのため、Redisの非同期レプリケーションのメリットとデメリットをそのまま引継ます。特に、リードレプリカが初めの1回でプライマリに繋ぐ、またはプライマリが変わった場合、レプリカとプライマリの間にフル同期が発生します。これによって、キャッシュデータを可能な限り最新状態にすることを保証します。ただし、プライマリやリードレプリカに追加の負荷をかけてしまいます。

すべてのフェールオーバー処理、検知から復旧まで、数分かかります。アプリのキャッシュレイアで、キャッシュが利用できない場合の処理(またはコード)が必要になります。

Available Now

この新しい機能はすべてのAWSリージョンに今すぐにご利用できます。この機能はすべてにElastiCacheユーザーに無料で提供しています。

-- 蒋

IAMコンソールの新機能:前回のAWSログインが一目でわかる一覧表示

$
0
0

AWS アカウント内のユーザが前回いつログインしたか素早く確認したかった事がこれまで無いでしょうか?あるいは、セキュリティのベストプラクティスに従い誰も AWS ルートアカウントを使ってログインしていない確認をしたかった事が無いでしょうか?もし、AWS CloudTrail を使っていれば、ログイン情報がログ内に記録されています。これは過去の履歴を遡って確認する必要がある場合は理想的ですが、ユーザが最近ログインしたかを一目見たいだけであればどうでしょうか?

AWS のパスワードが前回いつ使われたか確認できるように、IAM ユーザやルートアカウントで AWS マネジメントコンソール、AWS フォーラム、AWS サポートセンタ、AWS マーケットプレイスに前回ログインした日時が IAM (Identity and Access Management) コンソールに表示されるようになりました。これは2014年7月にリリースされた IAM ユーザのパスワードを管理するための認証情報ライフサイクル管理機能を基にしています。"前回のログイン"情報は IAM コンソールの一覧表示や認証情報レポートの両方で知ることができるのに加え、CloudTrail のログでより網羅的に知る事もできます。

IAM ユーザが前回いつログインしたか確認する方法、アカウント全体で前回いつログインしたかのスナップショットを残す方法を見てみましょう。

IAMユーザの"前回のログイン"情報を確認する

前回ログインした日時は IAM コンソールにあるユーザ一覧の属性の1つになっており、以下の通り "Password Last Used"という列に表示されます。:

個々のユーザをクリックすると、ユーザのパスワード、アクセスキー、MFA デバイスなどが表示されているセキュリティ認証情報の1つとして前回のログインが表示されています。

アカウント全体で"前回のログイン"のスナップショットをエクスポートする

ルートアカウントを含む全ユーザの前回のログインについてスナップショットを探している場合、認証情報レポートをダウンロードできます。レポートには、セキュリティ認証情報の状態、MFAが有効になっているかどうか、パスワードが前回いつ変更されたかなども含まれています。レポートは IAM コンソールで "Credential Report"をクリックしてか、プログラムから IAM API や AWS CLI を使ってダウンロードすることができます。IAM コンソールは以下の通りです。

この新しい機能をより詳しく学ぶには、IAM ユーザガイドを確認して下さい。IAM は AWS アカウントの機能で、追加の費用なしで利用できることも覚えておいてください。この機能は既に IAM コンソールで使えるようになっています。もしご質問があれば気軽にフォーラムに投稿してください。

CloudWatchアップデート - Windowsログファイルサポートの強化

$
0
0

今年の前半に、Amazon CloudWatchでのログの保管と監視の機能をローンチしました。かんたんにまとめると、この機能は Amazon Elastic Compute Cloud(EC2)インスタンスからCloudWatchにログファイルをアップロードし、堅牢な保存と特定のシンボルやメッセージの容易な監視を可能にするものです。

EC2ConfigサービスはEC2上のMicrosoft Windowsインスタンスで稼働し、いくつかの重要なタスクを担当しています。たとえばCloudWatchへのログファイルのアップロードなどになります。このサービスの強化により、WindowsパフォーマンスカウンタのデータとETW(Windowsのイベントトレース)ログをサポートしました。あわせてカスタムログファイルのサポートを追加しています。

 この機能を利用するためには、CloudWatch logsとの統合を有効にしてどのファイルをアップロードするのか指定する必要があります。インスタンスからEC2Configを起動してEnable CloudWatch Logs integrationにチェックをいれます:

%PROGRAMFILES%\Amazon\Ec2ConfigService\Settings\AWS.EC2.Windows.CloudWatch.json のファイルによってアップロードするファイルを指定します。

この機能の動作と構成の仕方についてもっとよく知るためには、AWS Application Management BlogにあるUsing    CloudWatch Logs with Amazon EC2 Running Microsoft Windows Serverをお読みください。

渡邉

DynamoDB Streamsについての事前情報

$
0
0

Amazon DynamoDBのアップデートについてちょっとした先出し情報をご案内したいと思います。この機能はAWS re:Inventでデモが発表され、まずは興味のあるみなさまに対して限定的に公開する予定です。

今日、多くのAWSのお客様がDynamoDBをアプリケーションのストレージとして利用しています。キーバリューストアとして利用している方々もいらっしゃれば、リレーショナルなスキーマをNoSQLのコンセプトに基づいて非正規化したデータを格納している方々もいらっしゃいます。また、最近リリースされたばかりのJSONサポートを利用してドキュメントストアとして利用されている方々もいらっしゃいます。

 

DynamoDB Streams

DynamoDBのテーブルの更新をリアルタイムにトラックしたいという声を非常に多く頂いていました。この背景としては、テーブルのアップデートにあわせて更新されるキャッシュレイヤをつくるためだったり、更新ごとにビジネスロジックを走らせるため、リアルタイムな分析をするため、別リージョンにリードレプリカをつくるためだったりとさまざまな用途が想定できます。

今回紹介するDynamoDB Streamsはこういったユースケースを実現してくれます。この機能を有効にすると、DynamoDBのテーブルに対するすべての更新(Put,Update, Delete)が直近の24時間分保持されるようになり、この更新のストリームデータに対してAPI経由でアクセスできるようになります。このAPIを利用すれば先ほど紹介したようなツールや機能を実装できるはずです。

もしあなたがモバイル、アドテク、ゲーム、ウェブ、IOTなどのアプリケーションをDynamoDBを利用して作っている/運用しているのであれば、この機能を利用することにより、既存のアプリケーションに手を加えることなく、流速の速いテーブルの更新をトラックし、ハンドリングすることができます。最近更新された無料枠(月あたり25GBのストレージと2億回のAPIリクエスト)を活用すれば、非常に小さな金額、もしくは無料でこの機能を試すことができると思います。

この機能はマネージメントコンソールからもアクセスできるようになる予定で、既存のDynamoDBのテーブルに対して「Modify Table」から有効化できるようになります。もちろん新規テーブル作成時にも有効化できます。一度有効化されれば「Streams」というタブにて更新のストリームを閲覧することができます。

このストリームは、DynamoDBテーブルのWriteプロビジョンスループットの約2倍のReadキャパシティを持ちます。たとえばある特定の大きさのアイテムを秒間1,000回の更新をするのに十分なキャパシティをプロビジョンされたテーブルであれば、秒間2,000回分はストリームから更新を読み取れるでしょう。ストリームはテーブルに対して行われたすべての更新(Put、Update、Delete)を保持します。また、ひとつのアイテムに対しての複数の更新は、その操作が行われた順番に沿ってシリアライズされます。これらのデータは常に直近24時間分が保持されます。テーブル自体が削除されたとしてもその間はストリームに対してアクセス可能です。

なお、Kinesis Client LibraryをDynamoDB Streamsをサポートできるように現在アップデートしているところです。Amazon CloudSearchAmazon Redshift、その他のAWSのサービスへのコネクタも提供していく予定です。

 

Get Started Today

Ddb_streams_xrr_library_java_1既に公開されている一部のドキュメントをご覧いただけばAPIのより詳細な情報を確認することができます。またこのドキュメントには、既に本機能が実装されたDynamoDB Localへのリンクや、本機能対応の更新が含まれたAWS SDK for JavaやKinesis Client Library、そしてマルチマスターのクロスリージョンレプリケーションを実現するためのライブラリなどへのリンク群が含まれています。

このCross Region Replication Libraryは、DynamoDB Streamsを利用して複数のリージョンをまたいでDynamoDBのテーブルをニアリアルタイムに同期するためのライブラリのプレビュー版です。あるひとつのリージョンにあるDynamoDBのテーブルへの更新を自動的に別のリージョンのテーブルへ伝播させてくれます。

このDynamoDB Streamsについては、できるだけ早くみなさまに続報をお伝えしていきたいと思っています。もしこの機能をできるだけ早く使い始めたいという方はぜひこちらのフォームから申し込みをおねがいします!またフィードバックも是非お願い致します!

今井

【AWS発表】コードの管理とデプロイのための新しいAWSのサービス群

$
0
0

今日はアプリケーションのリポジトリ管理、リリースワークフロー管理、デプロイのための新しいAWSのサービス群を紹介します!これらはアプリケーション開発者やシステム管理者のみなさんが、クラウド上で簡単かつ安全にアプリケーションを管理するために大きく役立ってくれるでしょう。まずはサービスラインナップを御覧ください。

  • AWS CodeDeploy - あなたのEC2 Fleet(日本語訳すると「EC2の艦隊」になりますが、かっこいいのでそのまま使います)に対して、サービスのダウンタイムをゼロ、もしくは最小にしつつ、効率的にコードをデプロイしてくれるサービスです。Fleetは1インスタンスから数万インスタンスまで、どんなサイズのものでも扱うことが可能です。
  • AWS CodeCommit - Gitリポジトリをホストするマネージドサービスです。これを利用することにより自身でリポジトリサーバーを管理する手間から開放されます。もちろん、既存のGit周辺ツールをそのまま利用することができます。

  • AWS CodePipeline - このサービスはリリースプロセスを自動化するのに役立ってくれます。必要に応じたワークフローを定義し、テスト、ステージング、本番といった様々な環境への開発中のコードデプロイや動作確認作業のようなフローを自動化することができます。もちろん、CodePipelineは様々なサードパーティーツールと一緒に利用することが可能です。

AWS CodeDeployは本日リリースされましたので、既にみなさん自身で試してみることができます。他の2つのサービスについてはリリースの目処が見えてきたらまたお知らせします。これらのツールは、もちろんそれぞれ独立して動作するように設計されています。さらに一緒に利用することによってより高い価値を提供するようになっていますので、リリースを楽しみにお待ちください。

AWS CodeDeploy

AWS CodeDeploy(以下、CodeDeploy)は、サービス停止が許されないミッションクリティカルな環境においての迅速な開発と迅速なデプロイにフォーカスを置いて設計されています。こちらも冒頭でお話したように、どんなサイズのEC2 fleetに対しても、ダウンタイムを発生させることなくコードをデプロイすることができます。CodeCommitはEC2のアップデート時にELBから一旦取り外したり、複数のAvailability Zoneに配置されたEC2群の高い可用性を失わないようにデプロイプロセスを進めてくれたりと、AWS上でのベストプラクティスが失わないようにケアをしてくれます。

CodeDeployの一番重要な仕事はもちろんのことアプリケーションのデプロイです。特定のアプリケーションのバージョンをEC2群に配布します。また、指定したスクリプトを起動させることもできます。これらの動作を記述するために、YAML形式のファイルが利用されます。ターゲットのEC2を指定するには、たとえばタグを利用したり、関連付けられているELBを利用したりします。

デプロイ対象のEC2インスタンスにはCodeDeployのエージェントソフトウェアをインストールして起動しておく必要があります。これはApache2.0ライセンスのもとで配布されるオープンソースソフトウェアで、LinuxもしくはWindowsで動作します。そしてアプリケーションコードの取得からパーミッションの設定、そしてスクリプトの起動などを司ります。エージェントのセットアップにはいくつか方法があります。1つはマネージメントコンソールでEC2起動のためにAMIを選択するときに「Deploy Ready」というチェックを入れ、インスタンス起動時に動作させることができます。もちろん、既に起動中のインスタンスに対してインストールすることも可能です。

CodeDeployはChefやPuppetと一緒に利用することもできます。また、EclipseやVisual Studioのプラグインとしても利用できますので、今までどおりの開発フローの中に組み込んで利用することができます。

このサービスももちろんマネジメントコンソール、CLI、API経由で利用できます。それでは、マネージメントコンソールを使ったデモアプリケーションのデプロイをひととおり試してみましょう。(このデモアプリケーションはマネージメントコンソールに同梱されています)非常に沢山のスクリーンショットがありますが、これらはほとんど最初のセットアップのためのものです。一度設定してしまえば、非常に多くのメリットを享受することができるでしょう。

デモはAWS CloudFormationを利用します。このテンプレートはCodeDeployDemoとタグ付けされた3台のEC2インスタンスを起動します。

Ci_1

そしてまずはアプリケーションを作成します。

Ci_2

それからデプロイのためのアプリケーションのリビジョンを作成します。このサンプルではS3に格納されていますが、もちろんこれはCodeCommitやGitHub上に格納されていても構いません。

Ci_3

CodeDeployが利用するIAM Roleを指定します。

Ci_4

次にDeployment Configurationが必要になります。デフォルトで用意されているもののなかからひとつを選んで利用することもできますし、自身で設定を作成することもできます。

Ci_5

自身でカスタムDeployment Configuraitonを作成する場合はこんな感じです。

Ci_6

最後にここまでの設定をレビューして、デプロイを実行します。

Ci_7

アプリケーションはDeployment Configurationに沿ってデプロイされていきます。コンソールは状況を逐次的に表示します。

Ci_8

一度設定を作ってしまえば、あとは数クリックで何度でもデプロイを実行できます。

Ci_9

AWS CodeCommit

アプリケーションのソースコードがみなさんの知的財産であることは間違いないでしょう。また、それはみなさんが時間と労力をかけてつくりあげた成果物であることも間違いないことでしょう!AWS CodeCommit(以下、CodeCommit)はこれらを安全に保管してくれるサービスです。すでに冒頭でお話したように、これはGitリポジトリをホストしてくれるマネージドサービスです。すでにお持ちのGitについての経験やツール群(CLIやIDEなど)は、もちろんそのまま活用することができます。このサービスを使い、いままでどおりチームでコードを編集したり、比較したり、同期することができます。

あなた(もしくはあなたの組織のクラウド管理者)は、CodeCommitのリポジトリを作成やパーミッションの設定、利用可能な状態にするなど一連の作業を非常に簡単に行うことができます。CodeCommitはコードやバイナリ、メタデータなどの冗長化された可用性の高いストレージに格納します。

CodeCommitはAWSクラウド上で動作していますので、開発者やチームが複数のロケーションに分散しているケースや、外部ベンダやパートナーと一緒に作業をするケースにも非常によくマッチします。会社のファイアウォールに穴をあけるなどの必要もありませんし、ストレージの容量なども気にする必要はありません。CodeCommitはチェックイン時にコードを暗号化して格納し、開発者や管理者からのアクセスはIAM Roleを使って識別します。

CodeCommitのコンソールのスクリーンショットを一部だけお見せしておきます。お楽しみに!
Ci_10

 

AWS CodePipeline

今日の多くのリリースプロセスは「スモークテストをして問題なければリリース!」というような単純なものではないでしょう。ワークフローが複雑になるほど、自動化の価値が高まってくるのは言うまでもありません。

AWS CodePipeline(以下、CodePipeline)はこのワークフローをコード化して自動化するのに役立ちます。これにより、インフラストラクチャのために割く時間をより小さくし、機能開発により多くの時間を割くことができるでしょう。これを利用すれば例えば、コミットされたコードや差分に対して、事前に定義されたテスト群が毎回自動的に実行され、コード自体やその品質に問題ないことを担保することができます。

CodePipelineではGUIを使ってリリースプロセスをモデル化することができ、直列、並列にさまざまなステージを定義できます。さらに時間ベースや、手動での承認を必要とするゲートを定義し、各ステージの間に配置することができます。たとえば新しい差分のステージングへのデプロイは、平日の日中の時間帯にのみ行う、というようなことを定義することができます。

CodePipelineはあなたのコードリポジトリの更新を監視し、それをトリガーにしてワークフローを起動することもできます。たとえば本番リリースのためのワークフローとして、自動的にリリース用ブランチのコードをビルドしてテストケースを実行し、ステージングサーバーにデプロイします。そして最終的に手動での承認(マニュアルゲート)を通って本番サーバー群にデプロイされる、といったようなことを実現することができるのです。

こちらがCodePipelineのコンソールのスクリーンショットです。
Ci_11

 

CodeDeployは今日リリースされましたので今すぐにでも使いはじめることができます!CodeCommitとCodePipelineについてもリリースを楽しみにお待ちください!

 

今井

【AWS発表】Amazon Aurora - Amazon RDSに費用対効果の高いMySQL互換のデータベースが登場!!

$
0
0

私達は2009年に、クラウド環境でMySQLのセットアップ・運用・スケーリングをサポートするためにAmazon Relational Database Service (RDS)をリリースしました。それ以来、マネージメントコンソールへの統合や、Oracle, SQL Server、そして、PostgreSQLの3つのデータベースエンジンのサポート、multi Availability Zone配置機能による高可用性など様々な機能追加を行ってきました。

 我々は、5年間で多くの改善と改良を行ってきました、しかし、機能を改善していく余地は常にあるのです!例えば、私が先ほど上げたデータベースエンジンは、制約のあるネットワークや性能が高くないCPU、HDDなどのシンプルなハードウェアや限定用途の並列処理、多くの並列度の高いI/O処理向けに設計されています。

RDSチームは、現状存在しているリレーショナルデータベースの様々な問題を見直し、解決し、さらにクラウドに適したリレーショナルデータベースを自ら作ることを決意しました。このプロジェクトは、RDSチームがまっさらなホワイトボードに、RDSの拡張性と信頼性を維持しながらも価格性能比を向上させるゴールを描くところからスタートしました。

そして、現在あるデータベースへの要求を満たすために効率的な、ストレージ・ネットワーク・コンピューティング・システムソフトやデータベースソフトウェアを作るチャンスだとRDSチームは気づきました。そして、この新しいシステムは、現在の新しいハードウェアの対応やI/Oウェイト、データベースプロセス間のロック競合を解消するように設計されました。さらに、スループットを大きく改善しつつ、可用性も向上させました。

 

Amazon Aurora – 新しいMySQL互換データベースの登場です!

本日、Amazon Auroraを発表します。Auroraはフルマネージドで、速度とオープンソースデータベースのシンプルさと費用対効果、さらにハイエンドの商用データベースの可用性を兼ね備えたMySQL互換のリレーショナルデータベースエンジンです。

Amazon RDS for Auroraを使っていただくことで、データベースを管理・チューニングする時間を最小限にし、ビジネスやアプリケーションの作成に注力することが出来ます。皆さんのビジネスの成長に合わせてAmazon Auroraも一緒にスケールしていきます。

もう、ストレージを追加するためにアプリケーションを止める必要は ありません。代わりに、Amazon Auroraが10GBから必要に応じて64TBまで自動でストレージを拡張していきます。

ストレージのベースパフォーマンスは高速で信頼性があり、予測可能なものになっています。ストレージ性能は保存されているデータ量に応じて線形に増加しますが、予測より高頻度のアクセスがあった場合はバーストも行われます。また、インスタンスサイズの変更も数分で行われ、リードレプリカの作成もほんの数クリックで完了します。

信頼性と高可用性のために、ストレージは自動的に3つのAWS アベイラビリティゾーン (AZs)内に複製され、さらに各AZ内で2つのコピーを作成します。これらの2種類(アベイラビリティゾーン内と他のアベイラビリティゾーンを使用)の冗長化機能によって、Amazon Auroraは一定数のディスクへ書き込みが行われた場合に書き込みが完了したと判断します。具体的には、 Amazon Auroraは6本全てのディスクへの書き込みを待たずに、6つのディスクの内少なくとも4つのディスクに書き込みが完了するとすぐに次の処理を実行します 。加えて、ストレージはSSDベースのディスクアレイに10GBずつのブロックで分散して書き込まれます。

これらの最適化によって、ホットスポットの影響を取り除き、非常に高い並列度を実現します。その一方で、自己修復機能も持っています。事実、Amazon Auroraは2つのディスク障害までは書き込みは継続し、3つのディスクが障害を起こしても読み込み処理を続けることが可能です。

この分散書き込みモデルはとても効率的で高速なAmazon Simple Storage Service (S3)へのバックアップを可能にします。なぜなら、書き込みは空き領域を使用し、バックアップはデータベースインスタンスへ負荷を与えずに高並列で行われます。

もし、インスタンス障害が発生した場合、Amazon Auroraはデータの欠損なしに障害の発生していないAZへリカバリを行うように設計されています。

また、Amazon Auroraは継続的で高速なバックアップを行います。皆様はこのバックアップを使用して1秒の粒度で過去の状態に復元することが出来ます(リストアはどのアベイラビリティゾーンにもリードレプリカが存在しない場合のみ必要です)

Amazon Auroraは99.99%の可用性を実現するように設計されました。インスタンスやディスクの障害が発生した場合、自動で復旧処理が行われます。

Amazon Auroraは、読み込みスループットの向上やフェイルオーバー先として15個のリードレプリカを作成することが可能です。これらのリードレプリカはプライマリインスタンスとストレージを共有しており、軽量で粒度の高いほぼ同期型のレプリケーションを行います (これらは、リードレプリカのページキャッシュにより、10-20ミリ秒オーダーの少ないラグで行われます)。

皆様のほとんどのMySQLを使用したアプリケーションは、変更なしに使用することが出来ます。もし、Amazon RDS for MySQLをお使いでしたら、数クリックでAmazon Auroraにマイグレーションすることが可能です。Amazon Auroraは MySQL5.6.10と機能面で互換性があり、今後のMySQLのリリースとも互換性を保っていく予定です。

 

Auroraデータベースインスタンスを起動しよう!

AWS Management Consoleから起動する手順をご紹介します。(Limited Previewの間はAWS Management Consoleからの起動のみサポートされます) AWS Command Line Interface (CLI), AWS CloudFormation template, and API support は現在開発中です。

 

Amazon AuroraはAmazon Virtual Private Cloud中に起動する必要があります。

まずは、Auroraエンジンを選択することから始めます

Aurora-mc

次に、データベースを稼働させるインスタンスタイプ、データベース名、DBAのアカウントを設定します:

Aurora-mc

 

最後に、いくつかの詳細設定を行います:

Aurora-mc-advanced

Amazon Auoraはストレージ容量を設定する必要がありません。ストレージは最初10GBで作製され、テーブルの容量が増加するにつれて自動で透過的にディスクサイズが拡張されます。Amazon AuroraではテーブルをInnoDBで作成する必要があります。そして、利用したストレージ容量のみ課金されます。

インスタンスが準備出来れば(約10分以内で完了します)接続先がコンソールに表示されます。

Aurora-monitor

 

RDSコンソールアップデート

今回、RDSのコンソールもアップデートされました。利用可能なRDSインスタンスそれぞれについて、タブ内に詳細情報が表示されます。(警告やイベント、設定そしてDBクラスタの詳細情報)

こちらが最初の画面です

Aurora-console

また、コンソールにいくつかのモニタリングのオプションが追加されました

Aurora-monitoring

フルスクリーンにモニタリングページを拡大することが出来ます (オペレーションルームの大型モニタに表示するのに適してますね)

Aurora-full

 

価格と利用について

Amazon Auroraは今までのデータベースよりも約4倍のパフォーマンスとコスト比を実現するために設計されました。今お使いのRDS for MySQLをAmazon Auroraに移行することで今までよりも小さいサイズのインスタンスで今まで同様の性能が出ることに気づくと思います。そして、Amazon Auroraでは実際に使用しているストレージ容量で課金されます。

Amazon Auroraを、US East (Northern Virginia)にてLimited Previewで公開します!Amazon Auror を体験してみたいと思ったら、こちらから Limited Previewにご応募下さい!

-- Jeff;  (日本語版は星野が担当しました)

【AWS発表】AWS Configを使ったAWSリソース構成の追跡

$
0
0

ダイナミックな性質はクラウドの最もクールな特徴の一つです。クラウドのリソースは、ものの数分で作成・アタッチ・設定・利用・デタッチそして削除することができます。これらの変更には、管理者の操作によるもの、 AWS CloudFormationによって操作されるもの、Auto Scalingをトリガーにして起こるものなどがあります。リソースそのものや、その接続性・設定・その他の属性は、時が経つにつれて変化していきます。

これらの変更が起きた際、組織のリソース管理者は、クラウド上の資産管理・在庫管理・変更管理・ガバナンスといった新たなチャレンジに直面します。管理者は、いつ・どんなリソースが変更され、その変更が他のリソースにどんな影響を与えたのかを知る必要があります。変更は時として、予期しない構成変更やシステム障害、またはセキュリティインシデントによって引き起こされたものである場合もあります。変更の原因にかかわらず、正しいデータにアクセスすることは、深く、データドリブンな分析を可能にします。

従来の構成管理ツールは、リソースや関連性が頻繁には変更されない時代に作られました。これらのツールは高価で、複雑で、管理者が色々な面倒を見る必要がありました。

AWS Configの紹介

我々はこれらのチャレンジにAWS Configを利用して取り組みます。この新しいAWSサービスは、あなたのAWSリソース(まずはEC2インスタンスと関連アイテム、その他のリソースについては計画中)の初期状態と関連性のキャプチャーおよび、作成・削除・プロパティ変更の追跡をおこない、それらを分析・可視化・保管します。

AWS Configはたった2クリックで有効化できます!有効化したら、Configはリソースやレコードの現状構成とあらゆる変更を検知します。構成データはAWS Management Console上でタイムラインとして参照できます。AWS ConfigはこれらのCIも提供します。構成変更は選択したAmazon Simple Notification Service (SNS)トピックにストリームされ、6時間毎にAmazon Simple Storage Service (S3)バケットにスナップショットがとられます。また、自作ツールやパートナーの提供するツールを利用して、収集したデータの分析をおこなうことも可能です。

AWS ConfigはAWSリソース間の関連性を解釈し、追跡します。EBSボリュームはEC2インスタンスにマウントされ、そのインスタンスはセキュリティグループ、 Elastic IP Addresses、VPC、Elastic Network Interfacesなどと紐付けられます。

AWS Configを利用すると、すべてのAWSリソースを可視化することができます。時系列の変更点を監視し、リソースの構成変更履歴を参照することができます。リソース間の接続性を確認することも、あるリソースの変更が関連するリソースにどのような影響を及ぼしたのかを見ることもできます。AWS Configは 定期的な変更が求められる環境で有益な情報を提供します!

すべてのAWSリソースに対して、それが組織のポリシーに適応したものかを確認することができます。例えば、プロダクション環境のVPCに属さないリソースをすべて洗い出す、過去2週間に特定のEIPアドレスが紐付けられたインスタンスを特定する、または、特定の日時のリソースの状態を知る、といったことが可能になります。

Configの利用方法
Configはアカウントごと、リージョンごとに有効化する必要があります。Configには、AWS Management ConsoleAWS Command Line Interface (CLI)、そして基本的なAPIセットからアクセスすることができます。

1

 まずは自分のアカウントで特定のリージョンを選択し、Configを有効化します。使用するSNSトピックとS3バケットはそれぞれ、新規作成、自アカウントの既存のもの、または適切な権限が設定された別のアカウントのものを利用することができます。

  2

AWS Configに自分のAWSリソースにアクセスするためのIAMロールを割り当てる必要があります。

  3

バケットにデータが格納されはじめ、変更通知がSNSトピックに送られます。バケットの見え方はこのような形です。

  4

実際には、Config用の自作ツールを構築する場合を除いて、このバケット内のデータを見ることはほとんどないと思います(データ構造の詳細を知りたい場合は下記のConfigデータの内容を参照してください)。その代わりに、Configコンソールや、サードパーティ製のツールを使います。Configコンソールでは、リソースを選択し、構成変更のタイムラインを確認することができます。

  5

 パートナーサポート

AWS Partner Network (APN)の皆様は、お客様の様々なユースケースに対応できるよう、AWS Configを利用した製品を提供しています。

Configパートナーは以下のとおりです。

  1. 2nd Watch
  2. CloudCheckr
  3. CloudNexa
  4. Evident.IO
  5. Red Hat Cloud Forms
  6. RedSeal Networks
  7. Splunk

それでは、彼らがどんなものを提供してくれるのか、彼らからのメッセージとスクリーンショットをご紹介します!

 

6
 

2nd Watchエンタープライズツールは、ユーザー環境にどんな変更が起きたのかをリアルタイム/プレイバックモードのそれぞれで可視化する機能を提供します。New Relicアプリケーションの警告、Amazon CloudWatch の警告、または AWS CloudTrailのイベントも統合し、簡単なワークロード管理を実現します。

  7


  8

AWS Configを利用すると、ユーザー環境の監査履歴の作成・管理をおこなえるようになります。ログは、セキュリティとコンプライアンスにとても貴重な情報を提供します。しかし、クラウドのダイナミックな性質は、ログの有効活用を難しくする場合もあります。CloudCheckrのコンプライアンスポリシーエンジンは、AWS CloudWatchのメトリックとCloudTrail のログを有益な情報に整形する機能をすでに提供しています。AWS Configによって、これらの機能はさらに拡張されます。

  9

  10


11
 

CloudnexaはAWSアカウント内のリソースのスナップショットと、監査用の変更履歴 を取得するためにAWS Configを統合します。AWS Configを利用することで、Cloudnexaはこれらの機能を構築するためのソフトウェアとインフラの設計、構築、メンテナンスが必要ありませんでした。

12
  13

 


  14

  15


16
 

Red Hat CloudFormsの利用者は、AWS Configを利用することでAmazon Web Services内で起動中のワークロードのコンプライアンス順守とポリシー強化を実現することができます。CloudFormsの利用者がすでに仮想環境とプライベートクラウドのワークロードを管理しているのと同じレベルのコントロールを、パブリッククラウドにも拡張することができます。

17
 


  18

AWS ConfigはAmazon S3の構成変更やAmazon VPCの構成履歴を保管・追跡します。RedSealの利用者は、AWS Configを利用することで、さらに多くの情報を取得し、AWSベースのネットワークの堅牢性を強化することができます。

19
 


20
 

Splunkは、アプリケーション、サーバー、ネットワーク、センサー、あるいはその他のシステムが生成した機械データを、利用者のビジネスに有効な形で収集し、インデックス化し、利用するためのソフトウェアとクラウドサービスを提供しています。AWS Configに統合されたSplunk App for AWSは、AWSリソース構成とリソース間の関連性を、リアルタイムおよび変更履歴という形で可視化します。このアプリケーションは、AWS ConfigとAWS CloudTrailのデータを関連付け、AWSアカウントのセキュリティとコンプライアンスを包括的に表示することもできます。

  21

22
 

 

Configデータの内容(開発者用)
それではConfigによって生成されるデータの中身を見て行きましょう。以下のデータは1つのEC2インスタンス構成のスナップショットデータです。このデータには、インスタンスの識別情報、割り当てられたタグ一覧および、紐付けられているセキュリティグループとEBSボリュームが記載されています。

{"configurationItemVersion":"1.0","configurationItemCaptureTime":"2014-10-28T02:30:36.989Z","configurationStateId":2,"relatedEvents":["f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"],"awsAccountId":"448164394201","configurationItemStatus":"OK","resourceId":"i-7053641e","ARN":"arn:aws:ec2:us-east-1:348414629041:instance/i-7053641e","awsRegion":"us-east-1","availabilityZone":"us-east-1b","configurationStateMd5Hash":"6ae267fafa03d87827137290c8b303e2","resourceType":"AWS::EC2::Instance","resourceCreationTime":"2013-04-26T19:36:06.000Z","tags":{"UserTagDemo":"TemporaryTag","Name":"RoadTripBlogServer"},"relationships":[{"resourceId":"sg-6e371c06","resourceType":"AWS::EC2::SecurityGroup","name":"Is associated with SecurityGroup"},{"resourceId":"vol-357a5f6c","resourceType":"AWS::EC2::Volume","name":"Is attached to Volume"}]}

Configは、変更を検知するたびにSNSトピックに通知を送ります。通知の中身は、詳細情報を含んでいます。

{"configurationItemDiff":{"changedProperties":{},"changeType":"CREATE"},"configurationItem":{"configurationItemVersion":"1.0","configurationItemCaptureTime":"2014-11-04T02:28:33.146Z","configurationStateId":1,"relatedEvents":["f8cdf490-3ddc-41ac-9cfd-9e1268dfba93"],"awsAccountId":"448164394201","configurationItemStatus":"ResourceDiscovered","resourceId":"vol-02fecb4d","ARN":"arn:aws:ec2:us-east-1:348414629041:volume/vol-02fecb4d","awsRegion":"us-east-1","availabilityZone":"us-east-1a","configurationStateMd5Hash":"16772ac8f8ccc7ed493a878f3bd88f8c","resourceType":"AWS::EC2::Volume","resourceCreationTime":"2014-11-04T02:25:10.281Z","tags":{},"relationships":[],"configuration":{"volumeId":"vol-02fecb4d","size":2,"snapshotId":"","availabilityZone":"us-east-1a","state":"available","createTime":"2014-11-04T02:25:10.281Z","attachments":[],"tags":[],"volumeType":"gp2","iops":6,"encrypted":false}},"notificationCreationTime":"2014-11-04T02:28:33.345Z","messageType":"ConfigurationItemChangeNotification","recordVersion":"1.2"}

また、Configは現在の構成のスナップショットを取得した際にも通知を送ります。

Config API
Configはリソースの構成情報を取得するための2つのAPIを提供します。

  • GetResourceConfigHistory - タイムレンジとリソースを指定して構成情報を取得します。
  • DeliverConfigSnapshot - リソースのスナップショットを作成し、S3に保管します。

Pricing and Availability
AWS Configは現在、US East (北ヴァージニア)リージョンでリミテッドプレビューとして利用できます。残念ながら現時点では東京リージョンでは利用できませんが、将来的には全てのAWSリージョンでAWS Configを利用できるよう計画しています。

Configは、あなたのAWSアカウントでサポートされているリソースの数量と構成変更回数(構成アイテム)に応じて課金されます。初期費用は必要ありませんし、いつでも利用を停止することができます。

1000個の構成アイテムに対して1月あたり3ドル課金されます。構成履歴ファイルと構成スナップショットのストレージとして、S3の標準料金が適用されます。また、SNS経由で通知をおこなった場合、SNSの標準料金が課金されます。

もし10000個の構成アイテムが毎月作成された場合、おそらくS3の料金は1月あたり0.13ドル以下になるでしょう。1月あたり100万回のSNS通知をAWS無料利用枠で利用できます(1万個の構成アイテムがある場合、1万回の通知を受けるでしょう)。

千葉


【AWS発表】AWS Service Catalogが近日登場

$
0
0

大規模な組織でのIT部門の運用は簡単ではありません。内部ユーザには最新かつ最高の効率的かつ創造的なテクノロジへのアクセスを提供したい一方で、ITの専門家としてコーポレートスタンダードをメンテナンスする必要があります。ベストプラクティスを集めると同時に、過剰な支出や無秩序な利用を抑制しなければならないでしょう。

数年前、アーリーアダプタ達は組織内でこっそりと、あるいはボトムアップでAWSを導入しました。アジャイルあるいはクラウドパワーのサクセスストーリーは瞬く間に広まり、上のレベルの人たちからも遅かれ早かれ注目されるようになりました。シャドウITはテクノロジの導入には実績のあるモデルですが、より統制がとれた方法が求められるのは不可避です。

私達は本当に長い間同じような話を大組織の方から聞き続けてきました。彼らはAWSを、ビジネスの生命線をサポートするアプリケーションや、内部の利用者にあらゆるサービスを届けるためにつかっています。彼らは組織内で、一貫性があり、レギュレーションに適合し、ベストプラクティスを広められ、なおかつ予算も管理できるように、組織内の細かな取り決めとAWSのもたらすメリットを両立させたいと望んでいます。

 Introducing the AWS Service Catalog

Image001

本日は、AWS Service Catalogの近日中の登場をお伝えしたいと思います。 これはちょうど上でまとめてみたようなニーズとチャレンジへの取り組みのためにデザインされました。 IT部門が内部のユーザに対して、一貫性と統制を管理された形でAWS上のサービスを提供するためのツールです。Service Catalogはサポートコストを削減し、再利用を奨励し、このブログで書いてきたようなクラウドコンピューティングの利点を組織内で実現する助けになると確信しています。

Service Catalogは本格的なAWSサービスで、2つの特徴的なユーザインターフェースを有しています。1つは管理者向け、もう1つは利用者向けです。また、インテグレーションとプロダクトマネージメントの助けとなるようなAPIのセットもあります。それでは、キーコンセプトとその目的をお話しましょう。

  • Service Catalog – サービスカタログは、1つのアカウントに存在します。これは、管理者は、1つもしくは複数のポートフォリオとして管理します。 
  • Administrator – 管理者の責任範囲は、ポートフォリオのアップロードと、サービスカタログ内のプロダクトポートフォリオ管理です。
  • User – ユーザは1つもしくは複数のポートフォリオで構成されるサービスカタログを閲覧し、興味のあるプロダクトを見つけ、ローンチします。ユーザは管理者と同じAWSアカウントでも、別のアカウントでも動作します。
  • Portal – ポータルは、サービスカタログの表示部で、ポートフォリオと製品を反映させ、個別のユーザがそれらにアクセスできるようにします。
  • Portfolio – ポートフォリオは、サービスカタログ内のバージョン付きのプロダクトの集合です。それぞれのポートフォリオは、IAM roleや、グループ、ユーザ名などのユーザセット毎にアクセス可能です。
  • Product – プロダクトは、AWSリソース(EC2インスタンス、アプリケーションサーバ、データベース等)の集合で、ユニット(AWSでいうところのスタック)として管理され、例示されます。プロダクトは、CloudFormationテンプレートで記述できます。複数の独立したバージョンのプロダクトは、1つのポートフォリオ内に並行して存在できます。

どうでしょう、登場する前に過度に複雑に感じてしまわないとよいのですが。ようするに、管理者はサービスカタログ内にポートフォリオを作成し、プロダクトをアップロードし、プロパティとパーミッションを設定します。ユーザはパーソナライズされたポータルを通じて、必要に応じたプロダクトを見つけてそれをローンチします。

みなさんがローンチできるようになった時には、さらに詳細を書くことにします。それまでは、あなたが使ってみたくなるようにクイックツアーをお見せしましょう。1つは管理者として、もう1つはユーザとしてのツアーです。以下のスクリーンショットは現在開発中のものであり、ローンチ時には異なる場合があります。

Service Catalog – 管理者ツアー
私は管理者です。マネージメントコンソールを起動し、Service Catalogを選択します。

Image003
 

ポートフォリオの作成は、名前と説明とオーナーを入力することで行います。さらに、必要ならタグを加えることもできます。

Image005
 

プロダクトをポートフォリオに追加できます。このプロセスは複数のスクリーンにわたって続きますが、シンプルです。まずプロダクトの記述からです。

Image007
 

次に、助けとなる情報、タグを入力します。

Image009
 

最後のステップは、CloudFormation テンプレートを明示します。

Image011
 

ポートフォリオの中に、プロダクトがあらわれます。

Image013
 

プロダクトにはユーザやグループ別のアクセス制御や制約をかけることができます。さらに、他のAWSアカウントにポートフォリオを共有させることもできます。

Image015
 

Service Catalog – ユーザツアー
ではユーザ視点でService Catalogを見て行きましょう。繰り返しになりますが、スクリーンショットは開発中のものです。

これが、パーソナライズされたポータルの全容です。

Image017

 

Products セクションには、私がローンチできるプロダクトがならんでいます。

Image019
 

数クリックで、プロダクトはローンチできます。

Image021
 

すると、Stacksセクションには、自分のアカウントで動作しているスタックが表示されています。

Image023
 

ご期待ください
AWS Service Catalog にすすんで、お知らせの通知を登録することができます。

ローンチ近くになったら、追加でお伝えすることが出てくると思います。続報をお待ちください。

荒木

 

【AWS発表】 AWS Key Management Service (KMS)

$
0
0

情報セキュリティはデータがクラウド上に保管されているか、オンプレミスに保管されているかに関わらず、常に最も重要なものです。AWSがその初期のころより、私達はお客様がどのようなアプリケーションやデータをクラウド上に移せるか、移すべきなのか十分に考慮して決断するために必要となる情報やサービス、機能を提供するためにベストを尽くしてきました。

暗号化がデータ保護戦略の主要な要素の一つであることに反対する人はいないと思います。これまで私達はお客様にAmazon Simple Storage Service(S3)のクライアントサイド、サーバーサイド暗号化や、Amazon Elastic Block Store(EBS)、Amazon Redshift、そしてAmazon RDS for OracleとAmazon RDS for SQL Serverのサーバーサイド暗号化といったいくつもの選択肢を提供してきました。これまでのところ、サーバーサイド暗号化のサポートは、それらのサービスがAWS内で生成、保管、管理される"マスターキー"を利用することで提供されてきました。

今日、私達はクラウド上のみならずオンプレミスで稼働するアプリケーションやサービスのマスターキーを管理することができる、新しくそして強力な鍵管理の選択肢を追加いたします!

AWS Key Management Service (KMS)の紹介

この新しいフルマネージドなAWS Key Management Service(KMS)は暗号化キーのシームレスで集中化された管理を提供するように作られています。このサービスはお客様にデータ保護の新しい選択肢を与え、エンタープライズスケールで鍵管理を導入する際に必ず遭遇するスケーラビリティや可用性といった煩わしい問題の多くからお客様を解放します。その適切な利用により、AWS Key Management Serviceはクラウド上に機密情報を置くことに対する懸念に対処することにも役立ちます。

このサービスはディスク上に鍵を保管しない、メモリー上に鍵を保持し続けない、そしてデバイスに接続できるシステムを制限するといった広範なハードニング技術により鍵を保護するシステム上に構築されています。サービスのソフトウェアアップデートを行うための全てのアクセスは、アマゾンの独立したグループによるレビューと監査を受ける多階層の承認プロセスにより管理されています。メンテナンスのためのすべての物理的なアクセスは厳しく管理され、記録されています(複数人の、シニアレベルの従業員が協業しなければいけません)。

 S3、EBS、RDSそしてRedshiftはAWS Key Management Serviceにより管理された鍵を用いて保管するデータの暗号化を行うことができます。お客様は各サービスのデフォルトのマスターキーを利用するか、AWS Key Management Serviceを利用してお客様自身の鍵を生成、管理するか選択することができます。お客様は各サービス、アプリケーションタイプ、データの分類ごとに鍵の利用を定義することができます。どのような選択であれこのサービスはどのマスターキーがデータを保護するのかまとめてくれます。どのようなオペレーションを選択したとしても、鍵に関する全ての通常の操作(生成、ローテート、有効化、無効化)はAWS Management Consoleや鍵管理用APIを通じて行うことができます。また鍵に関する全ての 操作はAWS CloudTrailに記録されます。お客様は特定の鍵がいつ、どのように使われ、そしてどのサービスが使ったのかそのログから知ることができます。

AWSのサービスのための鍵管理に加え、AWS Key Management Service(KMS)は豊富な鍵管理と暗号化APIを提供することにより、AWS及びオンプレミス上のアプリケーションに強固で完全に統合された暗号機能を付与するプロセスを合理化を行います。

AWS Key Management Serviceを利用した鍵の生成
早速鍵を作成してみましょう! Identity and Access Management Consoleを開き、Encryption Keysをクリックして下さい。この時点では既存の鍵を確認することができます(私のS3バケットやEBSボリューム、Redshiftのデータウェアハウスを暗号化するようにした際、KMSがこれらの鍵を作成しました。):

新しい鍵を作成するにはCreate Keyをクリックします。(簡単な3ステップの操作です)初めのステップは鍵に対するAlias(表示名)を指定し、デスクリプションを与えることです:

次に、一つもしくは複数のIAMユーザーやロールを選択することで誰が新しい鍵の管理を許されるか決める必要があります:

三番目のそして最後のステップとして、データの暗号化や復号化にその鍵の利用を許すユーザーやロール、他のAWSアカウントを決めます。このステップで決められたパーミッションはAPIによる直接の利用にも、KMSに統合されているAWSサービスでの利用にも適用されます:

EBSとS3での鍵の利用
さぁ、鍵が作られました。先ほど触れたどのAWSサービスでも(そして将来的にはその他でも)容易に鍵を利用することができます!こちらが作成した鍵で暗号化したEBSボリュームの作り方です:

そしてこちらがオブジェクトをS3にアップロードした後に暗号化するやり方です:

鍵の利用に関する管理と監査
鍵に関する全ての情報は1クリックで取得可能です:

鍵に対する全てのAPIリクエストはAWS CloudTrailにログされるため、利用者はいつ、どこで、だれによってどのように鍵が利用されたか追跡し、見て取ることができます。

鍵管理APIs
ここまで触れてきた全ての機能はプログラムによっても利用可能です。利用者は鍵の生成、削除、有効化、無効化を行うことができます。その鍵を利用することでデータの暗号化と復号化を行うことができます。また鍵ローテーションの有効可や無効化も可能です。AWS上やオンプレミスのアプリケーションはこうしたAPIを鍵管理と暗号化のために利用することができます。

新しいWhite Paper

KMSを利用した場合のAWSにおける暗号化の仕組みについてより知りたい方は私たちの新しいWhite Paper AWS KMS -  Cryptographic Detailsをダウンロードし、お読みください。

価格と利用に関して
この新しいサービスは全ての公式なAWSリージョンで本日より利用になれます。

(開始するためにAWS Key Management Service(KMS)のページをご覧ください。)

お客様は一つの鍵のバージョンにつき月々$1で鍵の生成と利用、管理を行うことが可能です。サービスに対するAPIリクエストは10000リクエストにつき$0.03になっています。一月あたり20000リクエストの無料枠を用意しています。

-- Jeff; (日本語訳は高田が担当しました)

【AWS発表】Amazon EC2 Container Service (ECS) - コンテナ管理のAWSサービス

$
0
0

最近、コンテナの技術があらためて注目されています。分散アプリケーションプラットフォームの基盤としてコンテナを使うと、一貫性、開発効率、運用効率などのメリットがあります。コンテナは非常に軽量であり、仮想マシンと比べて、より少ないメモリや計算オーバーヘッド達成することができ、小さな独立した数百、数千の「動く部品」からなるアプリケーションをサポートするのが非常に簡単です。適切にコンテナ化されたアプリケーションは、スケールさせたり保守するのが簡単で、システムリソースを効率的に利用することができます。AWSにおいてもこれまでAWS Elastic BeanstalkやAWS OpsWorksにおいてコンテナのサポートをしていることを紹介してきました(参照ブログ)。

Amazon EC2 Container Serviceの紹介

本日は、さらにコンテナのメリットを存分に活かせるように、新しいコンテナ管理のサービス、EC2 Container Service (略してECS) を発表致します!このサービスを用いると、Amazon Elastic Compute Cloud (EC2) インスタンスのクラスターにまたがる沢山のDockerコンテナを、パワフルなAPIやツールを用いて簡単に稼働させることができます。ECSを用いれば、もう、クラスター管理のソフトウェアをインストールしたり、クラスターハードウェアを購入したり保守したり、ソフトウェアの利用量にあわせてハードウェアの在庫を管理する必要はありません。単に、クラスターの中で好きなだけインスタンスを立ち上げ、タスクを定義し、スタートするだけです。ECSは、スケーラブルでフォールトトレラントで、マルチテナントであり、クラスター管理の詳細の全ての面倒をみてくれます。

ちなみに、クラスターといっても恐れることはありません。ここでいうクラスターとは単に、コンテナ化された複数アプリケーションをホストするための、コンピューター、ストレージ、ネットワークのリソースプールのことを指しています。実際、クラスターは単一のt2.microインスタンスでも構いません。一般的には、クラスターとして効率的に使うのに十分なリソースを持っている中くらいのサイズの一つのEC2インスタンスを使うことが多いでしょう。

EC2 Container Service

こちらがDockerベースのアプリケーションを作成、稼働、スケールさせる際におけるECSのメリットになります。

  • 簡単なクラスター管理 - ECSはDockerコンテナから成るクラスターをセットアップし管理します。ECSはコンテナの起動や終了を行い、クラスターのステート情報を保持します。複数のアベイラビリティゾーンにまたがる数万のコンテナを保持するクラスターに簡単にスケールすることができます
  • ハイパフォーマンス - アプリケーションのビルディングブロックとしてコンテナを用いることができます。数秒で数千のコンテナを起動、停止、管理できます
  • 柔軟なスケジューリング - ECSは組み込みスケジューラーを持っており、可用性、効率性の面でコンテナをクラスター上で適切に管理します。ECSはステート情報へのアクセスを提供しますが、もちろん、独自のスケジューラーや既存のオープンソースのスケジューラを用いてサービスAPIを利用することも可能です
  • 拡張可能でポータブル - ECSはオンプレミスで用いるのと同様のDockerデーモンを用います。オンプレミスで用いたものを容易にAWSに持ち込み、持ち出すことが可能です
  • リソースの効率的利用 - コンテナ化されたアプリケーションはリソースを非常に効果的に使えます。単一のEC2インスタンスの上で複数のお互いに関係のないコンテナを走らせることができます。例えば、同じインスタンスの上で、短期間だけ画像処理を行うコンテナと、長期間にわたって動かすWebサービス用のコンテナを同時に動かすことができます 
  • AWSの他サービスとの統合 - ECS上のアプリケーションは、もちろん、Elastic IPアドレスやリソースタグ、Virtual Private Cloud (VPC)といったAWSの機能を利用できます。コンテナはEC2やS3と同様に新しいレベルのビルディングブロックとして用いることができるでしょう
  • セキュアなサービス - VPCの中のEC2インスタンスでタスクを動かすことができます。タスクはIAMロール、セキュリティグループなどのAWSセキュリティ機能を活用できます。コンテナはマルチテナント環境で動作し、定義されたインタフェースを通じてお互いに会話することができます。コンテナが稼働するEC2インスタンスも完全に所有しコントロールできます。

EC2 Container Serviceの利用

ECSは、簡単にセットアップして利用できるように設計されています。

ECS有効AMIを起動すると、インスタンスは自動的にデフォルトのクラスターにチェックインされます。もし異なるクラスターに起動したい場合は、定義ファイルを編集する、もしくは、起動の際にUser Dataに引き渡すことで特定することができます。Linux AMIをECS有効にするには、単純にECSのエージェントとDockerデーモンをインストールするだけです。

ECSエージェントはオープンソースとしてApacheライセンスの下で利用可能です。既存のLinux AMIにインストールすれば、registerContainerInstancesのAPIを呼ぶことでクラスターに追加することができます。 

ECSで使われる用語集は以下の通りです。

  • クラスター (Cluster) - クラスターは特定のAWSリージョンのEC2インスタンスのプールで、ECSに管理されます。ひとつのクラスターは、異なるインスタンスタイプとサイズを含むことができ、複数のアベイラビリティゾーンにわたって配置できます。
  • スケジューラー (Scheduler) - スケジューラーは各クラスターにひもづけられます。スケジューラーはコンテナをインスタンスにアサインし、クラスター内のリソースを最適に利用する責任を持ちます。スケジューラーはリソースの配置上の制約を理解し出来るだけ並列に稼働させて高い可用性を実現します
  • コンテナ (Container) - コンテナはパッケージ化されたアプリケーションコンポーネントです(英語ではDockerizedとも言います)。クラスター内の各EC2インスタンスは複数のコンテナをホストすることになります
  • タスク定義 (Task Definition) - コンテナのためにタスクを定義するJSONファイルです。ファイルの中のフィールドは各コンテナのイメージを定義し、メモリやCPUの条件をきめ、コンテナがお互いに会話するためのポートマッピングを特定します
  • タスク (Task) - タスクは、タスク定義を実行したもので、実行する仕事が定義されています
  • ECS有効AMI (ECS-Enabled AMI) - ECSエージェントを稼働させるDocker化されたAmazon Machine Image (AMI)です。Amazon Linux AMIをECS有効にしたものを提供する予定ですし、CoreOSやRHEL、UbuntuのAMIも提供できるように取り組んでいます。

EC2 Container Serviceは、シンプルでパワフルなAPIセットを提供しています。クラスターの作成、表示、削除ができ、そのクラスターの中にEC2インスタンスを登録できます。タスク定義を作成でき、タスクの起動と管理が行えます。

ECS上でアプリケーションを起動するには以下の手順をとります。この例ではすでにお手持ちのアプリケーションがDocker用になっている、つまり、適切な粒度のコンポーネントになっており、各アプリがDockerfileで表現されており、既存のインフラの上で適切に動いていると仮定しています。すでにオンライン上にこういったリソースは沢山見つけられるでしょう。人気のあるアプリケーションコンポーネントはすでにDocker用になっており、Docker Hubで発見することができます。Docker repositoryにアクセス可能であれば、それがパブリックであろうとプライベートであろうとECSを用いることができます。こちらがその手順となります。

  1. 指定のリージョンでクラスターを作成します。アカウントに設定されたデフォルトのものを利用することもできます
  2. タスク定義を作成し、クラスターに登録します
  3. EC2インスタンス(複数可)を起動し、クラスターに登録します
  4. 各タスクにおいて望みのコピー数を起動します
  5. クラスターにおける全体の利用率とアプリケーションのスループットを監視し、調整します。例えば、利用可能なクラスターのリソースプールを拡張するために、追加のEC2インスタンスを起動して登録できます

EC2 Container Serviceの料金と利用形態

今回の発表はプレビューの形式をとっています。もしサインアップすることに興味がありましたら、こちらをクリックして登録してください。ECSに追加の料金は必要ありません。通常通り、実際に使って頂いた分だけ利用料金を支払って頂く形となります。

玉川 (Facebook, Twitter)

【AWS発表】さらに大容量で高速なElastic Block Store(EBS)ボリューム

$
0
0

Amazon Elastic Block Store(EBS)のユーザに素晴らしいお知らせがあります。従来よりも大容量で高速なEBSボリュームを利用できるよう拡張を行う計画があることを、WernerがAWS re:Inventにて発表いたしました。

新しいスペックはこちらです:

  • General Purpose(SSD):最大16TBの容量、最大10,000IOPSのベースパフォーマンス(もともと1TB/3,000 IOPSが最大値でした)。この種類のボリュームは引き続きより高いパフォーマンスを発揮するバースト機能をサポートしています
  • Provisioned IOPS(SSD):最大16TBの容量、最大20,000IOPSまでのパフォーマンスを指定可能(もともと1TB/4000プロビジョンIOPSが最大でした)


Fasterebs

新たに作成されたEBSボリュームは、従来のものと比較して2倍以上高速にデータ転送を行えるようになります。最大スループットは、General Purpose(SSD)では160MB/s、Provisioned IOPS(SSD)では320MB/sとなります。

最大容量とパフォーマンスが拡張されたことにより、複数のボリュームのストライピングを構成することなしに大規模なワークロードを処理することができます。ストライピング構成に付きものだった複雑なsnapshotの管理も不要ですので、データの管理やアプリケーション開発といった本質的な作業に注力することができます。

いつからご利用頂けるようになるかについては、続報をお待ちください!

小林

【AWS発表】AWS Lambda – クラウド上でのコード実行

$
0
0

私たちはクラウドで実行するアプリケーションのビルドをより簡単にしたいと考えています。コードに集中できるようになって欲しいですし、スケーラビリティや信頼性、ランタイム効率が当たり前のことのように十分に高いクラウド中心の環境で働いて欲しいと思います!

AWS Lambdaのプレビューを本日ローンチすることを発表させて頂きます。AWS Lambdaはクラウドでアプリケーションをビルドして実行する新たなプラットフォームで、既存のプログラミングスキルやAWSに関する知識を活用することができます。 Lambdaを用いて、シンプルにLambda functionを作成し、特定のAWSリソースへのアクセス許可を与え、そしてLambda functionをAWSリソースへと接続します。Lambdaは変更をAmazon Simple Storage Service (S3)のバケットにアップロードされたファイルへの変更やAmazon Kinesisのストリームに届いたメッセージ、Amazon DynamoDBにおけるテーブルの更新を受けてあなたが用意したコードを自動的に実行します。

Lambdaは全く管理が要らないコンピューティングプラットフォームです。EC2インスタンスを設定したり、起動、監視したりする必要はありません。OSやプログラミング言語の環境をインストールする必要もありません。スケールや耐障害性を考慮する必要もないですし、キャパシティをリクエストしたり確保したりする必要もありません。新たに作られたLambda functionはユーザ側で全く何もすることなく、また非常に高い費用対効果に基づいて1時間あたり数万のリクエストを扱うことができるようになっています。

もう少しLambdaの中身を掘り下げて見ていきましょう。プログラミングモデルとランタイム環境を少し見てから、プログラミング例をひと通り見ていきます。今回のポストを読むことで、Lambdaのロードマップ上にはたくさんの項目があるということと、今日皆さんに共有できることはこれからずっと続く機能に満ちた旅のほんの最初の一歩であるということを心に留めて置いてください。

Lambda のコンセプト

1

Lambdaの最も重要なコンセプトはLambda functionです(単にfunctionという場合もあります)。Node.jsJavaScriptのイベントドリブンなサーバサイド実装です)でLambda functionを記述します。

コードをアップロードし、Lambda functionを作成するためAmazon Lambdaに対してコンテキスト情報を設定します。コンテキスト情報では実行環境(言語、必要なメモリ量、タイムアウト期間やIAM role)を指定し、コード内で実行したい関数を示します。コードとメタデータはAWS上で永続的に保存され、後から名前やARN (Amazon Resource Name)で参照可能です。必要なサードパーティライブラリもアップロードに含めます(Lambda functionごとに単一のZIPファイル形式となります)。

アップロード後、自分のLambda functionと特定のAWSリソース(特定のS3バケット、DynamoDBテーブルもしくはKinesisストリーム)を紐付けます。LambdaはLambda functionに対してイベント(一般的にはリソースが変更されたことを意味します)をルーティングするようにします。

リソースに変更があると、Lambdaはそのリソースに紐付けられたLambda functionを実行します。受信リクエストを処理するため必要に応じてコンピュートリソース(EC2インスタンス)を起動し管理します。何も気にしなくて大丈夫です、Lambdaがあなたの代わりにリソースの管理を行いますし、必要なくなればそれらのシャットダウンも行います。

Lambda はAWS Management Console,  AWS SDK, そして AWS Command Line Interface (CLI)からアクセス可能です。Lambda APIは全てドキュメント化されており、既存のコードエディタやその他の開発ツールをLambdaに接続するのに使うことができます。

Lambda のプログラミングモデル

Lambda functionは紐付けられたリソースが変更された後、有効化されます。指定されたNode.jsの関数で実行が開始され、そこから処理が進みます。関数は(POSTと一緒に渡されたパラメータを通して)JSON形式のデータ構造にアクセスします。このデータ構造にはLambda functionが有効化されるきっかけとなる 変更(もしくはその他のイベント)に関する詳細な情報を含みます。

Lambdaはリソース変更のペースに遅れをとらないよう必要に応じてLambda functionの追加コピーを有効化します。Lambda functionはコンピュートインスタンス上に永続的な状態を保存することはできないので、代わりにS3もしくはDynamoDBを使用する必要があります。

コードではNode.jsおよびLinuxの環境下で本来備わっている機能を利用可能です。その他のAWSサービスを呼び出すためにAWS SDK for JavaScript in Node.jsを利用することもできます。

Lambda の実行環境

各Lambda functionに指定したコンテキスト情報はファンクションの最大実行時間を指定します。これは一般的に短めにセットされますが(数秒でも多くの処理ができるはずです)、必要に応じて最大60秒まで指定することが可能です。

Lambdaは複数のIAM roleを用いてLambda functionへのアクセスとAWSリソースを管理します。Invocation roleはLambdaに特定のLambda functionを実行する権限を与えます。Execution roleはLambda functionに特定のAWSリソースへのアクセス権限を与えます。きめ細かい権限の組み合わせを実現するためにそれぞれのファンクションに対して別個のIAM roleを使用することが可能です。

Lambdaは各Lambda functionの実行を監視し、リクエスト数、遅延、可用性とエラー率のメトリクスをAmazon CloudWatch内に保存します。メトリクスは30日間保持され、コンソール上で見ることができます。 

どのようにLambdaを使うか考えはじめるときに考慮すべき点がいくつかあります。

  •  Lambda functionのコンテキスト情報では実行に必要なメモリ量も指定します。128MBから1GBまでの間で好きな値を指定可能です。メモリ設定に応じてLambda functionが利用可能なインスタンスのCPU能力、ネットワーク帯域、IO帯域が決まります。
  • 各Lambda functionの起動は最大で256のプロセスもしくはスレッドを使用できます。最大512MBのローカルストレージと1024までのファイルディスクリプタも使用できます。また、最大で10の同時アウトバウンド 接続も生成します。
  • Lambdaは各AWSアカウントにおいて一連の管理上の制限を課します。プレビュー期間中は同時進行の起動リクエストを25個まで処理することが可能です 。 

Lambda入門

それではマネージメントコンソールを使ってシンプルなLambda functionを作成するプロセスを見て行きましょう。先だって述べた通り、これらはSDKCLIから実施することも可能です。以下のコンソールでは私の全Lambda functionを表示しています。

2

手始めにシンプルに「Create a Lambda function」をクリックします。それから詳細について全て入力します。

3

 次のように自分のLambda functionに名前を付け、説明書きを加えます: 

4

それから、コードを直接入力するかZIPファイルをアップロードします。コンソール上では始めるのに役立つサンプルのコードスニペットの選択もできます。

5

どのLambda functionを実行するか、実行時にどのIAM roleを利用するかを指定します。 

6

メモリ要件の微調整と実行時間の制限も設定できます。

7

Lambda functionの作成後、コンソール上で繰り返し編集しテストすることができます。見て分かるとおり、左ペインにはLambda functionに渡されるJSONデータのサンプルが表示されています。

8

Lambda functionが期待通りに動いているならば、Amazon S3 event notificationのようなイベントソースをアタッチできます。Lambda functionの起動のために必要となる権限をS3に与えるため、Invocation roleを指定します。

9

前述の通り、Lambdaは各Lambda functionごとにメトリクス情報を収集し、それらをAmazon CloudWatchに送ります。コンソール上でメトリクスを見ることができます。

10

ロードマップ

私たちはLambdaに関する素晴らしいロードマップを持っています。今日はその全てを伝えることはしませんが 、さらなるAWSサービスと言語のサポートを追加する予定であることをお伝えします。いつものように、私達はお客様からのフィードバックを非常に大切にしています。ぜひLambda Forumにコメントを残してください。

料金と利用可能なリージョン

まとめに入る前に料金について少し話しましょう!Lambdaはきめ細やかな料金体系となっています。100ミリ秒単位のコンピュート時間と個々のリクエストに対する支払いとなります。 Lambdaの無料枠は一月あたり100万リクエストと一月あたり最大320万秒のコンピュート処理時間が含まれます。コンピュート処理時間はLambda functionごとに割り当てられたメモリの合計量によります。 Lambdaは本日よりUS East (Northern Virginia), US West (Oregon), と Europe (Ireland)リージョンで限定プレビューが利用可能です。使い始めるには今すぐ登録をお願いします!

 

-- 西谷

Viewing all 446 articles
Browse latest View live