Author: AWS Japan Staff


Amazon AuroraでCross-Region Read Replicaがご利用頂けるようになりました

Amazon Auroraクラスタににリードレプリカを追加することでリードキャパシティの増強を行って頂けます。本日、リードレプリカを他のリージョンに作成頂ける機能をリリースしました。この機能を利用することでリージョン間でディザスタリカバリ構成を利用出来、リードキャパシティを拡張出来ます。その他にも、他のリージョンにデータベースをマイグレーションしたり、新しい環境を構築する際にもご利用頂けます。

リードレプリカを他のリージョンに作成すると、Auroraクラスタがそのリージョンに作成されます。Auroraクラスタには15台までリージョン内であればレプリカラグのとても低いリードレプリカを作成出来ます(多くのケースで20ms以内)。リージョン間の場合、ソースクラスタとターゲットクラスタの間の距離に応じてレイテンシが増加します。この構成は、現在のAuroraクラスタを複製したり、ディザスタリカバリ目的でリードレプリカをリージョン間で構成することに利用頂けます。リージョン障害が万が一発生した場合、クロスリージョンレプリカをマスターとして昇格します。こうすることで、ダウンタイムを最小限にすることが可能です。こちらの機能は、暗号化されていないAuroraクラスタに適用可能です。

リードレプリカを作成する前に、ターゲットとなるリージョンにVPCやDatabase Subnet Groupsが存在しているか、マスターでバイナリログが有効になっているかを確認する必要があります。(訳者注: 設定を有効にする前に最新のパッチを適用して下さい)

VPCの設定

AuroraはVPC内で起動するため、ターゲットとなるリージョンに適切に設定されたDatabase Subnet Groupsが存在するか確認します:

con_aurora_cross_target_subnet_groups

バイナリログを有効にする

クロスリージョンレプリケーションを設定する前にバイナリログを有効にする必要があります。もしdefaultパラメータグループをお使いの場合、新しいDB Cluster Parameter Groupを作成します:

con_aurora_create_cluster_pg

バイナリログを有効にし(binlog_formatをMIXEDに)、Save Changesをクリックします:

con_aurora_edit_cpg

次に、設定を変更するDBインスタンスを選択しModifyを選択します。そして、新しいDB Cluster Parameter Groupを選択しApply Immediatelyを選択してContinueをクリックします。変更を確認し、設定を反映させるためにをクリックします:con_aurora_pick_cpg

インスタンスを選択し、再起動を実行しreadyになるまで待ちます

リードレプリカの作成

事前準備が完了したら、リードレプリカを作成します!AWS Management Consoleから、ソースクラスタを選択し、 Instance ActionsメニューからCreate Cross Region Read Replicaを選択します:

con_aurora_cross_reg_replica_menu

新しインスタンスやクラスタの名前を設定し、ターゲットリージョンを選択します。DB Subnet Groupを選択し、他のオプションも希望の設定にし最後にCreateをクリックします:

con_aurora_create_cr_replica

Auroraがクラスタやインスタンスを作成します。インスタンスが作成されデータがレプリケーションされるまでcreatingステータスになります(作成完了までの時間はソースクラスタに保存されているデータサイズに依存します)。

こちらの機能は本日からご利用頂けます!

— Jeff (翻訳は星野が担当しました。原文はこちら)

Amazon ElastiCache アップデート – RedisのSnapshotをAmazon S3へエクスポートする事が可能になりました

Amazon ElastiCache はポピュラーなインメモリキャッシュエンジンであるMemcachedRedisをサポートしています。
Memcachedは低速なディスクベースのデータベース等の結果を高速にキャッシュする事ができ、Redisは永続的にデータを保存できるデータストアとして高速に動作します。Redisはレプリケーションやフェイルオーバなどをサポートすることでの高可用性の確保と、複雑なデータ構造での保存を標準サポートしています。

 

本日Redisユーザのみなさんに、非常に興味深く、注目すべき新しい機能をリリースしました。まず、実行されているRedis キャッシュクラスタのスナップショットを作成する事は既に可能です。スナップショットは永続的なバックアップや、新しいキャッシュクラスタを作成するために使用することができます。おさらいとしてキャッシュクラスタのスナップショットを作成する方法は次のとおりです:

RedisスナップショットがS3バケットへとエクスポートできるようになりました。S3バケットはスナップショットと同一リージョンに存在し、ElastiCacheに適切なIAMの権限(List、Upload/Delete、View 権限)を付与する必要があります。この機能はいくつかの用途を想定しています:

 

ディザスタリカバリ – スナップショットを他の場所にコピーし保管する

分析 – S3上のスナップショットのデータから使用状況等を分析する

種データ配布 – 別のリージョンにスナップショットを元にした新しいRedisキャッシュクラスタを構築する

スナップショットのエクスポート
スナップショットをエクスポートするのは簡単です、スナップショットを選択し、Copy Snapshot をクリックしてください:

バケットのアクセス許可を確認してください。(詳細はExporting Your Snapshotを参照ください):

次に、新しくエクスポートするスナップショット名と希望する保存先のS3バケット名を入力してください:

ElastiCache はスナップショットをエクスポートし、指定したS3バケットにスナップショットを置きます:

ファイルは標準のRedisのRDBファイルとして保存され、使用することができます。

また、アプリケーション等のコードや、コマンドラインからも同様の作業を実行することができます。対象のS3バケットを指定し、プログラムコードから呼び出す場合はCopySnapshot、コマンドラインからはcopy-snapshotコマンドを使用してください。

この機能は既に利用可能で、本日から使い始めることができます!エクスポートには料金はかからず、通常のS3ストレージ料金だけで使うことができます。

— Jeff;

翻訳はSA桑野(@kuwa_tw)が担当しました。原文はこちら

 

 

Amazon RDS for Oracleで拡張モニタリングがご利用頂けるようになりました

Amazon RDS for Oracleにて、拡張モニタリングがご利用頂けるようになりました。拡張モニタリングでは、DBインスタンスの56種類のシステムメトリクスやプロセスメトリクスを確認頂けます。

拡張モニタリングは既に、 MySQL, MariaDB, Amazon Aurora, PostgreSQL, SQL Serverでご利用頂けていました。本日から、全ての RDS for Oracleインスタンスでご利用可能になりました。拡張モニタリングはAmazon RDSインスタンスの状態をリアルに詳細に確認していただけます。インスタンスのプロセス情報をまとめ、56種類のシステムメトリクスを1秒単位で取得出来ます。RDSコンソールでメトリクスをビジュアライズ出来ますし、Amazon CloudWatchやサードパーティアプリケーションともインテグレーション可能です。

利用可能なメトリクスの全てのリストや詳細なAmazon CloudWatchとの連携に関する情報は拡張モニタリングドキュメントページをご覧ください。RDSインスタンスのモニタリングのために、拡張モニタリングをシームレスにサードパーティアプリケーションと連携するための詳細情報はAmazon CloudWatchドキュメントをご覧ください。

拡張モニタリングは t1.micro及びm1.smallを除く全てのRDS for Oracleインスタンスでご利用頂けます。拡張モニタリングを有効にすると、CloudWatch Logsの料金が課金されます。利用料金に関する詳細はCloudWatch Logs pricingページをご覧ください。

Amazon RDS for Oraclの拡張モニタリングは本日から、 US East (Northern Virginia), US West (Northern California), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Seoul), South America (Sao Paulo) , Asia Pacific (Tokyo)リージョンでご利用頂けます。

星野 (原文はこちら)

EC2インスタンスのコンソールスクリーンショット

ユーザーがAmazon EC2を使用するために既存のマシンイメージをクラウドに移行するとき、ドライバや起動パラメータ、システム構成、そして進行中のソフトウェアアップデートなどによる問題に出くわすことがあります。これらの問題によってインスタンスにRDP(Windowsの場合)やSSH(Linuxの場合)経由で接続できなくなり問題判別を難しくします。従来のシステムでは、物理コンソールでログメッセージや何が起きているのかを特定して理解するための手がかりが見つかることがあります。

インスタンスの状態をより可視化しやすくするために、インスタンスコンソールのスクリーンショットを生成してキャプチャできる機能を提供します。インスタンスが稼働中またはクラッシュした後にスクリーンショットを生成することができます。

こちらがコンソールからスクリーンショットを生成する方法です(インスタンスはHVM仮想化を使用している必要があります):

そしてこちらがその結果です:

Windowsインスタンスでも使用することができます:

CLI (aws ec2 get-console-screenshot)またはEC2 API(GetConsoleScreenshot)を使用してスクリーンショットを作成することもできます。

いますぐ利用可能
この機能は本日から米国東部(北バージニア)、米国西部(オレゴン)、米国西部(北カルフォルニア)、ヨーロッパ(アイルランド)、ヨーロッパ(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、アジアパシフィック(シドニー)、そして南アメリカ(ブラジル)リージョンで利用可能です。これに関連する追加コストはありません。

Jeff;

翻訳はSA渡邉(@gentaw0)が担当しました。原文はこちら

 

Amazon Elastic TranscoderでMPEG-DASHをサポートしました

Amazon Elastic Transcoderはビデオやオーディオといったメディアファイルを元の形式から他の形式にコンバート可能なサービスです。このサービスはロバスト、スケーラブルでコスト効果が高く簡単にご利用頂けます。ご利用頂くにはpipeline(処理で使用するインプットとアウトプットのS3バケットのペアを指定します)を作成し、トランスコードのjobを作成します。それぞれのjobはインプットバケットから処理対象のファイルを読み込み、jobで指定されたフォーマットへトランスコードを行いアウトプットバケットへ書き込みます。トランスコード(Standard Definition (SD) video, High Definition (HD) video, audio)に応じて課金を行います。トランスコードプリセット(アウトプットフォーマットとそれに関連する設定の集合)をご提供しています。お客様のご要望やエンコード技術の変化に応じて新しいプリセットやフォーマットを追加してきました。例えば、先日VP9 Codecをサポートしました。

MPEG-DASHサポート

本日、MPEG-DASH フォーマットのサポートを開始しました。このフォーマットは、HTTPサーバを用いて高画質・高音質のストリーミングをサポートします。また、アダプティブストリーミングの技術を用いて、ネットワークスループットの状況に応じてビットレートを変えて配信可能です。この技術は様々なデバイスやビットレート環境に適しており、トランスコードプロセスを簡素化し、様々なフォーマットを作成することを避けることが出来ます。

MPEG-DASHのトランスコードプロセス中に、コンテンツは様々なビットレートのセグメンとにトランスコードされ、それぞれの出力を参照するためのプレイリストが作成されます。クライアントは最初にプレイリストをダウンロードします。その後、ネットワーク帯域やレイテンシを監視し、必要なビデオセグメントを要求します。再生中にネットワーク状況が変化した場合、プレイヤは状況に応じて、ビットレートの高い(低い)セグメントを要求します。

トランスコード済みのコンテンツはS3から直接配信することも出来ますし、Amazon CloudFrontを使用して、ユーザに最も近い場所から配信することも可能です。どちらの場合でも、以下の様なCORSポリシーを作成する必要があります。

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <CORSRule>
     <AllowedOrigin>*</AllowedOrigin>
     <AllowedMethod>GET</AllowedMethod>
     <MaxAgeSeconds>3000</MaxAgeSeconds>
     <AllowedHeader>*</AllowedHeader>
  </CORSRule>
</CORSConfiguration>

CloudFrontを利用する場合は、OPTIONSメソッドを有効にして、キャッシュされることを許可します

ets_dash_allow_http_methods

加えて、3つのヘッダをディストリビューションのwhitelistに追加します

ets_dash_whitelsit_headers

MPEG-DASHでトランスコード

MPEG-DASHでアダプティブビットレート機能を利用する場合、1つのトランスコードjobで別々のプリセットを利用して複数のアウトプットを作成します。これらのプリセットを選んで頂けます(ビデオ向けに4つ、オーディオ向けに1つ)

ets_pick_dash_presets

このフォーマットを利用する際、適切なセグメントデュレーション(秒)を選択します。短いデュレーションを設定すると多くの小さいセグメントを生成し、クライアントが回線状況の変化により高速に適応出来ます。

全てのビットレートを含んだ、1つのプレイリストを作成するか、みなさまの多くのお客様やコンテンツに適した特定のビットレートを選択可能です。また、ご自身のプリセットを既存のプリセットを元に作成出来ます。

ets_edit_preset

すぐにご利用頂けます

MPEG-DASHサポートは本日から、Amazon Elastic Transcoderをご利用頂ける全てのリージョンでご利用頂けます。こちらのフォーマットを利用するための追加料金は必要ありません。料金の詳細は Elastic Transcoder Pricingをご覧ください。

— Jeff (翻訳は星野が担当しました。原文はこちら)

Amazon ECSでAuto Scaling

Amazon EC2 Container Service (Amazon ECS)のClusterを自動的にスケールさせる方法はありましたが、本日Auto ScalingとAmazon CloudWatchのAlarmに追加された新機能により、ECSのServiceにScaling Policyを利用することができます。ServiceのAuto Scalingにより、需要が高まった時にスケールアウトさせて高い可用性を実現したり、需要が下がったらServiceとClusterをスケールインさせることでコストを最適化するのを、全て自動でリアルタイムに行うことができます。

この記事では、Clusterを需要に合わせて自動的にリサイズさせつつ、この新しい機能がどうやって利用できるかをお見せします。

Service Auto Scalingの概要

すぐに利用できるECS Serviceのスケーリング機能はずっと一番要望を受けていて、ついに今日この機能をアナウンスでき嬉しいです。自動でスケールするServiceの作成手順はとても簡単で、ECSコンソールやCLI、SDKでもサポートされています。希望するTaskの数とその最小・最大数を選択し、1つ以上のScaling Policyを作成すると、後はService Auto Scalingが面倒を見てくれます。Service SchedulerはAvailability Zoneを意識してくれるので、ECSのTaskを複数のZoneに渡って分散するように心配する必要もありません。

それに加えて、ECS Taskを複数AZ Cluster上で実行することも非常に簡単です。ECS ClusterのAuto Scaling Groupが、複数Zoneに渡る可用性を管理してくれるので、必要とされる回復力や信頼性を持つことができ、ECSがTaskのZone間の分散を管理してくれるので、皆さんはビジネスロジックに集中することができます。

利点:

  1. 来ているアプリケーションの負荷にキャパシティを対応させる: ECS ServiceとECS ClusterのAuto Scaling Groupを両方にScaling Policyを使います。必要に応じて、Cluster InstanceとService Taskをスケールアウトさせ、需要が落ち着いたら安全にスケールインさせることで、キャパシティの推測ゲームから抜け出せます。これによって、ロングランな環境で低コストな高可用性を実現できます。
  2. 複数AZのClusterでECSの基盤に高い可用性を持たせる: Zone障害という可能性から守ることができます。Availability Zoneを考慮しているECS SchedulerはCluster上のTaskを管理し、スケールし、分散してくれるので、アーキテクチャは高い可用性を持ちます。

Service Auto Scalingのデモ

この記事では、これらの機能を使い真にスケーラブルで高い可用性を持ったMicroservicesアーキテクチャを作成する手順を辿りたいと思います。このゴールに到達するために、以下の様な手順をお見せします:

  1. Auto Scaling Groupで2つ以上のZoneにECS Clusterを作成する。
  2. そのCluster上にECS Serviceを設定し、希望するTaskの数を定義する。
  3. ECS Serviceの前段にElastic Load Balancingのロードバランサを設定する。これが負荷の入り口になります。
  4. ECS Service用のスケールインとスケールアウトのCloudWatch Alarmを設定する。
  5. ECS Cluster用のスケールインとスケールアウトのCloudWatch Alarmを設定する 。(注: 前のステップで作成したものとは別のAlarmになります)
  6. ECS Service用のScaling Policyを作成し、スケールアウトとスケールインする時のScaling Actionを定義する。
  7. ECS Clusterが動いているAuto Scaling Group用のScaling Policyを作成する。これらのPolicyはECS Clusterのスケールイン・アウトで利用されます。
  8. 負荷を徐々に増やしたり減らしたりすることで、スケーラブルなECS ServiceとClusterの高可用性をテストする。

この記事では、Cluster上に1つのECS Serviceを設定する手順をお見せしますが、このパターンは同じCluster上で複数のECS Serviceを実行する時にも適応できます。

注意: この例を実行した結果、発生した如何なるAWSのコストも支払う必要があります。

概念図

ECS ServiceのAuto Scalingを設定する

Auto Scalingを設定する前に、複数AZ (2 Zone)のCluster上で実行されていて、ロードバランサを前段に持つECS Serviceを作っておく必要があります。

CloudWatch Alarmを設定する

  1. Amazon CloudWatchのコンソール上で、ECS Serviceのスケールインとスケールアウト時に使われるCloudWatch Alarmを設定します。このデモではCPUUtilization (ECS, ClusterName, ServiceNameのカテゴリから選びます)を使いますが、他のMetricsを使うこともできます。(注: 他のやり方として、Service用のScaling Policyを設定する時にはECSのコンソール上でこれらのAlarmを設定することもできます。) 
  2. AlarmにECSServiceScaleOutAlarmという名前をつけ、CPUUtilizationの閾値を75に設定します。
  3. Actionの所でNotificationを削除します。このデモではECSとAuto Scalingのコンソールを使ってActionを設定します。
  4. 上記の2ステップを繰り返してスケールインのAlarmを作成し、CPUUtilizationの閾値を25にして、演算子を”<=”に設定します。
  5. Alarmsの所で、スケールインのAlarmがALARM状態にあるはずです。今のところECS Serviceに負荷がかかっていないので、これは期待した状態です。
  6. ECS Cluster用のCloudWatch Alarmを設定するために、前のステップと同じことをします。今度は、CPUReservation (ECS, ClusterNameから選びます)をMetricとして利用します。前のステップの様に2つのAlarmを作成し、1つがECS Clusterのスケールアウト用、他方がスケールイン用とします。それらにECSClusterScaleOutAlarmとECSClusterScaleInAlarm という名前(または自由な名前)を設定します。

注: これはCluster固有のMetricですが(Cluster-Service固有のMetricと対照的)、このパターンでも有効的ですし、複数ECS Serviceのシナリオでも有効です。ECS Clusterはどれが起因であってもClusterの負荷に応じて常にスケールします。

ECS ServiceのスケールはECS Clusterのスケールに比べてとても速いので、ECS ClusterのスケーリングのAlarmをECS ServiceのAlarmよりも敏感にしておくことをお勧めします。こうすることで、スケーリングの間Clusterに余分なキャパシティが常にあることを保証でき、一瞬の負荷のピークに対応することができます。もちろん気をつけるべきは、この余分なEC2のキャパシティでコストは増えるので、Clusterのキャパシティを確保するのとコストの間で良いバランスを見つける必要がありますが、それはアプリケーション毎に異なるでしょう。

ECS ServiceにScaling Policyを追加する

Add a scale out and a scale in policy on the ECS service created earlier.

先ほど作成したECS ServiceにスケールアウトとスケールインのPolicyを追加します。

  1. ECSコンソールにサインインし、Serviceが動いているClusterを選択、Servicesを開いてServiceを選択します
  2. Serviceのページでは、Updateを選択します。
  3. Taskの数が2になっていることを確認します。これはそのServiceが実行する時のデフォルトのTask数です。
  4. Update ServiceのページのOptional configurationsの下にある、Configure Service Auto Scalingを選択します。
  5. Service Auto Scaling (optional)のページのScalingの下にある、Configure Service Auto Scaling to adjust your service’s desired countを選択します。Minimum number of tasksとDesired number of tasksの両方に2と入力します。Maximum number of tasksには10を入力します。ECS Serviceの作成時にホスト(EC2インスタンス)上の80番ポートをECS Containerの80番ポートにマッピングしているので、Auto Scaling GroupとECS Taskが両方共同じ数値になっていることを確認しておいて下さい。
  6. Automatic task scaling policiesセクションの下の、Add Scaling Policyを選択します。
  7. Add Policyのページでは、Policy Nameに値を入力します。Execute policy whenには、前に作成したCloudWatch Alarm (ECSServiceScaleOutAlarm)を入力します。ActionではAdd 100 percentを設定し、Saveを選択します。
  8. 上の2つのステップの繰り返しで、前に作成したスケールインのCloudWatch Alarm (ECSServiceScaleInAlarm)を使ってスケールインのPolicyを作成します。ActionではRemove 50 percentを設定し、Saveを選択します。
  9. Service Auto Scaling (optional)ページで、Saveを選択します。

ECS ClusterにScaling Policyを追加する

ECS Cluster (Auto Scaling Group)にスケールアウトとスケールインのPolicyを追加します。

  1. Auto Scalingのコンソールにサインインしてこのデモ用に作成したAuto Scaling Groupを選択します。
  2. DetailsからEditを選択します。
  3. DesiredとMinが2に、Maxが10に設定されていることを確認して、Saveを選択します。
  4. Scaling PoliciesからAdd Policyを選択します。
  5. まず、スケールアウトのPolicyを作成します。Nameに値を入力し、Execute policy whenは前に作成したスケールアウトのAlarm (ECSClusterScaleOutAlarm)を選択します。ActionではAdd 100 percent of groupを設定し、Createを選択します。
  6. 上のステップを繰り返して、スケールインのPolicyをスケールインのAlarm (ECSClusterScaleInAlarm)を使って、ActionにはRemove 50 percent of groupを設定します。

Auto Scaling Group用のスケールインとスケールアウトのPolicyを見ることができるはずです。これらのPolicyを使って、Auto Scaling GroupはECS Serviceが動いているClusterのサイズを大きくしたり小さくしたりできます。

注: ClusterのScaling Policyをこの様に設定することで、Clusterに幾つかの余分なキャパシティを確保することになります。これによってECS Serviceのスケールアウトはより高速になりますが、同時に、需要に依ってはいくつかのEC2インスタンスが利用されない状態になることがあります。

以上でECS ServiceとAuto Scaling Groupに対して、今回はそれぞれ異なるCloudWatch Alarmによって発動するようにAuto Scalingの設定が完了しました。異なるCloudWatch Alarmsの異なる組み合わせを使ってそれぞれのPolicyをもっと凝ったScaling Policyとすることもできます。

これでスケールアウトできるキャパシティを持ったCluster上で動作するServiceができあがったので、Alarmが発動するようにロードバランサにトラフィックを流してみましょう。

ECS Serviceスケーリングの負荷試験

それでは、Apache abツールを使いECS Serviceに負荷試験をして、スケーリングの設定が動作するかを確認してみます(負荷試験インスタンスの作成の章をご覧ください)。CloudWatchのコンソールで、Serviceがスケールアウト・インする様子が見られます。Auto Scaling Groupが2つのAvailability Zoneを使う用に設定されているので、各Zoneに5つのEC2インスタンスを見ることができるはずです。また、ECS Service SchedulerもAvailability Zoneを意識するので、Taskも2つのZoneに渡って分散しているでしょう。

EC2コンソールから、手動でEC2インスタンスを終了させることで高可用性の試験もできます。Auto Scaling GroupとECS Service Schedulerが、追加のEC2インスタンスを起動しTaskも起動してくれるはずです。

追加で考慮すべきこと

  • キャパシティの確保: 既に書いた様に、ECS Clusterに余分なキャパシティを確保しておくことで、Clusterが新しいインスタンスを準備するのを待たなくて良いので、ECS Serviceのスケールアウトがとても高速になります。こちらはCloudWatch Alarmが発動する値を変更するか、Scaling Policyの値を変更することで簡単に実現できます。
  • インスタンスの終了保護: いくつかのスケールインのケースでは、利用できるECS Clusterのキャパシティが減少することで、強制的にTaskが終了したり他のホストに移動してしまいます。こちらはECS ClusterのスケールインのPolicyを需要に対して敏感に反応しないように調整するか、EC2のホストが終了する前にうまくTaskが終了できるようにすることで軽減できます。そのためには、別の記事で解説されているAuto Scaling Lyfecycle Eventインスタンスの終了保護をご覧頂くと良いと思います。

今回のデモではAWSコーンソールを使いましたが、もちろん同じことをAWS SDKやCLIを使って実現することも可能です。

まとめ

ミッションクリティカルなMicroservicesアーキテクチャを動かす時には、トータルでかかるコストを下げることは非常に重要ですし、加えて負荷を複数のZoneに分散できることや、ECS ServiceとClusterのキャパシティを負荷の変化に合わせて調整できることが必要になります。この記事でご紹介した手順では、2軸でのスケーリングを活用することでこれを実現することができます。

補足

2016年7月21日に全てのリージョンで利用可能となりました。 https://aws.amazon.com/about-aws/whats-new/2016/07/amazon-ec2-container-service-automatic-service-scaling-region-expansion/

原文: https://aws.amazon.com/blogs/compute/automatic-scaling-with-amazon-ecs/ (翻訳: SA岩永)

Amazon Auroraでアカウント間でスナップショットを共有頂けるようになりました

Amazon AuroraはMySQL互換で、ハイパフォーマンスなデータベースエンジンです。Auroraはハイエンドデータベース速度や可用性をオープンソースデータベースのコスト効率やシンプルさでご利用頂けます (更に詳細な情報はAmazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDSをご覧ください)。AuroraはAmazon RDSでご利用頂ける、簡単な管理数クリックでスケール可能スピードセキュリティコスト効率などの幾つかの重要な機能を持っています。

数クリックでAuroraクラスタのバックアップを行うためにスナップショットを作成出来ます。スナップショットを作成後、同じく数クリックでスナップショットからデータベースをリストア可能です。

スナップショット共有

本日、Auroraスナップショットを共有頂けるようになりました。スナップショットは他のAWSアカウントと共有するだけではなく、パブリックに共有も可能です。同一リージョンの他のAWSアカウントで起動しているAuroraスナップショットからデータベースをリストア可能です。

スナップショット共有の主なユースケースをいくつかご紹介します:

環境の分離 – 多くのAWSのお客様が開発、テスト、ステージング、プロダクション環境に個別のAWSアカウントをご利用しています。必要に応じでこれらのアカウント間でスナップショットを共有頂けます。例えば、初期データベースをステージング環境で構築し、スナップショットを作成します、そしてそのスナップショットを本番環境のアカウントに共有し、そのスナップショットから本番データベースを作成します。他にも、本番環境のコードやクエリで何か問題が発生した場合、プロダクション環境のデータベースのスナップショットを作成しテスト環境にデバッグ目的で共有することも可能です。

Partnering – 必要に応じてスナップショットを特定のパートナーに共有出来ます

データの共同利用 – もしリサーチプロジェクトを行っているなら、スナップショットを作成しパブリックに共有することが可能です。興味をもった人がそのスナップショットから自分のAuroraデータベースを作成し、皆さんのデータをスタートポイントとして利用出来ます。

スナップショットを共有するために、RDSコンソールからShare Snapshotをクリックします。そして、共有先のAWSアカウントを入力します。(もしくは、パブリック共有のためにPublicを選択します)そして、Addを選択します:

rds_aurora_share_snap

共有出来るスナップショットは、手動作成されたもの、暗号化されていないものを他のAWSアカウントと、パブリックなものを共有可能です。自動取得されたスナップショットと暗号化されたスナップショットは共有出来ません。

共有されたスナップショットは直ぐに他のアカウントで閲覧出来るようになります:

rds_aurora_see_shared_snaps

パブリックスナップショットも参照出来ます(FilterAll Public Snapshotsを選択します):

rds_see_public_snaps

本日からご利用頂けます

この機能は本日から直ぐにご利用頂けます。

— Jeff (翻訳は星野が担当しました。原文はこちら)

I Love My Amazon WorkSpaces!

昨年のはじめに私の同僚、Steve Muellerがオフィスにきてわたしが興味を持ちそうなインターナルのパイロットプログラムについて教えてくれました。彼はAmazonネットワークでAmazon WorkSpacesを動かす準備ができたと言ってウェイティングリストへの登録をオファーしてくれました。もちろん、人柱になるのが好きな人間なので、私はオファーを受けることにしました。

つかいはじめる
その後すぐに私は2画面のスクリーンとたくさんのメモリがあるそれなりにちゃんとしたオフィスのデスクトップでWorkSpaces clientを動かしはじめました。そのとき私は勤務時間中にそのデスクトップを使用して出張や在宅勤務では別のラップトップを使用していました。Amazon WorkDocsを使用して2つの環境でファイルを共有していたものの、切り替えにはいくつかの困難がありました。異なったブラウザタブ、ブックマークなどです。どうやっても、環境をまたがってオフィスアプリの構成を同期させて管理することができませんでした。

オフィスでWorkSpacesを数週間つかった後、私はデスクトップと同じくらい高速によく反応することに気づきました。そのときから、私はWorkSpacesをメインの作業環境として徐々にかつて信頼していたデスクトップとの縁を切りました。

私は週に2~3日在宅で勤務します。自宅のデスクトップは2つの大画面スクリーンと、たくさんのメモリ、最高級のメカニカルキーボードがあり、Ubuntu Linuxを動かしています。Linux上ではVirtualBoxとWindows 7を動かしています。言いかえると、高速で高ピクセルな環境です。

オフィスのWorkSpaceが快適だったので、自宅にクライアントをインストールしてつかいはじめました。それは偉大な前進で私にとってひらめきの瞬間でした。高速で、高ピクセルの自宅環境から仕事環境へアクセスできるようになりました。

ここでクライアント仮想化とサーバー仮想化の組み合わせは低速で、ラグが多く、ローカルデバイスよりも応答が悪いと思われるかもしれません。それは事実ではありません!私は極端に要求がうるさいユーザーです。早撃ちのごとくキーボードをたたき、大量のウィンドウを開いて、フェレットのようにalt-tabで切り替え、そしてシステムがちゃんと動くことに対して極端に非寛容です。私のWorkSpaceは高速でよく反応し、さらにより生産的にしてくれます。

Zero Clientへの移行
私のWorkSpacesジャーニーから数ヶ月して、SteveがIMしてきてパイロットプログラムのメンバーにZero Clientを利用できるようにする計画があると言いました。私はそれを気に入ったので参加することに同意しました。彼と相棒のMichael GarzaがSteveのデスクの下のスペースにおいてあったDell Zero Clientと2個のピカピカの新品のモニターをセットアップしてくれました。その時点で私のオフィスのデスクトップは用済みとなりました。私はそれを取り外して、その功績に敬礼し、コピールームにあるハードウェア返却棚に運びました。私はWorkSpaceとZero Clientにオールインし、完全に依存するようになりました。

Zero Clientは小さくて静かなデバイスです。ファンや内蔵ストレージはありません。単にローカルの機器(ディスプレイ、キーボード、マウス、スピーカー、そしてオーディオヘッドセット)とネットワークに接続するだけです。フル機能のデスクトップよりも熱や電力がはるかにすくなくてすみます。

そのとき私はかなり国内および海外出張をしていました。私は旅先からWorkSpaceにログインしはじめました。やってみると、単一の統一された仕事環境がオフィス、自宅、そしてラップトップまで広がりとてもクールなことに気づきました。ファイルやアプリ群にどのデバイスからアクセスすることができました。私はどこからでもアクセスできるポータブルなデスクトップを手に入れたのです。

ローカルの計算能力ではなくリモートのWorkSpaceを使用しているという事実はわりとすぐ意識の裏側に消えていきました。ある朝私は「私のWorkSpaceが消滅した!」という挑発的なタイトルの電子メールをチームに送信しました。彼らはそれを読んでパニックになって、私がドッキリをしかけたにちがいないと思ったので私は彼らに対して自分のWorkSpaceにではなく自分の仕事にフォーカスできるようになったのだとシンプルに伝えました。私はどれもシリアスなものではないいくつかのバグをレポートしましたが、すべてとても迅速に対処されました。

ラップトップ死亡
移行が現実的であったことは昨年の終わりのある朝ラップトップのハードディスクが故障したときに明らかになりました。私はそれをITヘルプデスクにもっていきディスクを修理しました。そしてオフィスにもどって、WorkSpaces clientを再インストールして、仕事を続けました。ほかのアプリをインストールしたりファイルをコピーすることはありませんでした。この時点で私のラップトップにある唯一の個人的なアイテムはWorkSpaceの登録コードとステッカーだけでした!カンファレンスやお客様向けプレゼンテーションでどのような回線が利用できるかわからないため、まだPowerPointをローカルで実行しています。

私はまたWorkSpacesを差別化してよりよいものにしているほかの何かに気づきはじめました。ラップトップはポータブルで壊れやすいため、そこに格納した情報を一時的なものとして考えがちです。心の奥底ではいつか悪いことが起こってラップトップとその中身を失ってしまうことを知っています。WorkSpacesへの移行はその心配を取り去ってくれました。私はファイルがクラウドに格納しておりラップトップがなくなっても根本的には取るに足らないことだと知っています。

ちゃんと動く
私の同僚であるJames Hamiltonの言葉を借りると、WorkSpacesはちゃんと動きます。それはローカルデスクトップとまったく同じようなルックアンドフィールとふるまいをします。

前に言ったように、私は要求のうるさいユーザーです。2つの大画面モニターがあり、たくさんのオフィスアプリを動かし、多すぎるくらいのブラウザウィンドウとタブを開いています。これまでは仮想デスクトップにあまり適していなかったようなこともやっています。たとえば:

画像の編集 – このブログのすべてのスクリーンショットをキャプチャして編集しています(ありがとう、Snagit)。

音声の編集AudacityをつかってAWS Podcastsの編集をしています。今年は新機能のaudio-in supportをつかってWorkSpace上でポッドキャストを録音することを計画しています。

音楽Amazon Musicプレイヤーをインストールしてブログ中にお気に入りの曲を聞いています。

動画 – 社内向けと外向けの動画を視聴しています。

印刷 – 社内ネットワークのプリンタにいつもアクセスしています。自宅にいるときは、家庭内ネットワークのレーザーとインクジェットプリンタにもアクセスします。

WorkSpaceはAmazonのネットワークで動作しているので、ローカルの速度制限や帯域幅にかかわらず大容量のファイルをダウンロードすることができます。こちらがスピードテストの結果です(Bandwidth Placeによる):

変わらない感覚
昨年の終わりにパイロットWorkSpacesから本番環境に移行して現在はAWSチームの多くのメンバーにWorkSpacesがプロビジョンされています。私のWorkSpaceは私のポータブルなデスクトップです。

1年以上WorkSpacesを使用して、私はローカル環境との最大のちがいはテクニカルなものではないと言わなければなりません。それよりも、単にちがう(そしてよりよい)と感じます。強い変わらない感覚があります—私がどこにいようと、私のWorkSpaceが私の環境です。ログインするとき、私の環境はいつも以前のままです。1~2週間くらい不在にしていたあとにラップトップを開いたときにしていたように、電子メールの同期やパッチのインストールを待つ必要はありません。

タグ付けが可能に
エンタープライズが大量の台数のWorkSpacesを評価、採用、そしてデプロイするときに、コスト割り当てのために利用をトラックできる機能を必要としていました。多くの場合彼らはどのWorkSpacesがどの部門、そして/またはプロジェクトで使用されているのかを見たいと思っていました。本日WorkSpacesのタグ付けのサポートをローンチしました。WorkSpaces管理者はAWS Management ConsoleAWS Command Line Interface (CLI)、またはWorkSpaces APIを使用してそれぞれのWorkSpaceに10個までのタグ(キー/バリューのペア)をアサインできるようになりました。タグされると、コストがAWS Cost Allocation Reportで可視化されてレポーティングのために必要なように細切れにすることができます。

こちらがWorkSpaces管理者がコンソールを使用してWorkSpaceのタグを管理しているところです:

タグは本日からWorkSpacesが利用可能なすべてのリージョンで利用可能です:米国東海岸(北バージニア)、米国西海岸(オレゴン)、ヨーロッパ(アイルランド)、アジアパシフィック(シンガポール)、アジアパシフィック(東京)、そしてアジアパシフィック(シドニー)です。

もっとよく知る
私の体験に納得してもっとよく知りたいと思ったのであれば、こちらがはじめるにあたってのリソースになります:

  • Amazon WorkSpaces ホームページ – テクニカルと価格の完全な情報があります。
  • Amazon WorkSpaces Testimonials – ヤマハ発動機、Endemol Shine Nederland、そしてルイジアナ州更正課がWorkSpacesをどのように利用しているのか知ることができます。
  • Deploying Amazon WorkSpaces at Scale with Johnson & Johnson – あるエンタープライズのお客様によるプレゼンテーションの詳細です。
  • How Amazon.com is Moving to Amazon WorkSpaces – どのようにしてネットワーク構成を決めたのかについてたくさんの情報をふくむ私たちの体験についての詳細な物語です。私は「お客様」として最後にすこし登場しています。
  • AHEAD Desktop As a Service – どのようにしてAWSパートナーのAHEADがWorkSpacesを使用してDesktops as a Service (DaaS)を提供しているのか知ることができます。彼らの記録されたwebinarに登録して視聴することもできます。

デモのリクエスト
あなたやその組織がAmazon WorkSpacesの恩恵を受けられると思ってもっとよく知りたいのであれば、workspaces-feedback@amazon.comで私たちのチームまでご連絡ください。

Jeff;

翻訳はSA渡邉(@gentaw0)が担当しました。原文はこちら

EC2のX1インスタンス – メモリー重視のワークロードに対応可能

多くのAWSのお客様はメモリー性能を必要とするビッグデータ、キャッシング、および分析系のワークロードを実行しており、増え続けるメモリー量に対応したEC2インスタンスについてのご要望をいただいていました。

昨年の秋、初めて新しいインスタンスタイプX1についての計画をお伝えしました。今日、このインスタンスタイプのインスタンスサイズx1.32xlargeが利用可能になったことを発表します。このインスタンスの仕様は以下です:

  • プロセッサー: 2.3GHzの4 x Intel™ Xeon E7 8880 v3 (Haswell) – 64コア / 128 vCPUs
  • メモリー: Single Device Data Correction (SDDC+1)を実現した1,952 GiB
  • インスタンスストレージ: 2 x 1,920 GB SSD
  • ネットワーク帯域幅: 10 Gbps
  • 専用のEBS帯域幅: 10 Gbps (デフォルトでEBS最適化、追加料金不要)

Xeon E7 プロセッサーはターボ・ブースト2.0(最大3.1GHzまで)、AVX 2.0AES-NI、そして非常に興味深いTSX-NI命令をサポートしています。AVX 2.0(Advanced Vector Extensions)は、HPCやデータベース、ビデオ処理といったワークロードの性能を向上できます; AES-NIは、AES暗号化を使用するアプリケーション速度を向上します。新しいTSX-NI命令は、トランザクションメモリーと呼ばれる素晴らしい機能をサポートします。この命令は、並列性が高いマルチスレッドアプリケーションにおいて、メモリーアクセスを必要としたときに行われる低レベルのロックとアンロックの数を削減することで、非常に効率的な共有メモリーの使用を可能とします。

X1インスタンスは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)、欧州(フランクフルト)、アジアパシフィック(東京)、アジアパシフィック(シンガポール)、そしてアジアパシフィック(シドニー)リージョンで準備ができており、利用申請をしていただければできるだけ早く稼働させようと思っています。また、あまり遠くない将来に、X1インスタンスを他のリージョンで、および他のインスタンスサイズを提供する計画があります。

米国東部(バージニア北部)リージョンの場合、3年契約の一部前払いで1時間あたり3.970ドルでご利用いただけます; 詳細な情報はEC2の料金ページをご覧ください。今日時点で、リザーブドインスタンスDedicated Host Reservationsを購入することができます; スポット価格は短期的なロードマップにあります。

x1.32xlargeが動いているスクリーンショットをいくつか記載します。lscpuで4ソケットにわたり128vCPUsが搭載されていることが表示されています:

システム起動時のカーネルがアクセス可能な総メモリーです:

topコマンドでは膨大な数のメモリーとプロセスが表示されています:

エンタープライズ規模のSAPワークロードに対応可能
X1インスタンスは、本稼働ワークロードにおけるSAP認定を取得しています。SAP HANAに必要とされるSAP OLAPとOLTPの両ワークロードの性能要件を満たしています。

お客様は、オンプレミスからAWSに移行できますし、もちろん新規構築することもできます。次世代ビジネススイートSAP S/4HANA、または以前のバージョンのどちらも稼働させることができます。

現在、多くのAWSのお客様が、複数のR3インスタンスを並べたスケールアウト構成でSAP HANAを稼働させています。これらのワークロードの多くは1台のX1インスタンスで実行できるようになります。この構成であれば、構築も容易で、運用コストも抑えられます。後述していますが、構成オプションの詳細情報は最新のSAP HANA Quick Start にて提供いたします。

X1インスタンスで実行された環境をSAP HANA Studioでみると次のようになります:

X1インスタンスでSAP HANAを稼働させる場合、災害対策(DR)や高可用性(HA)においても複数の興味深いオプションがあります。例えば:

  • 自動リカバリー – RPO (Recovery Point Objective)とRTO(Recovery Time Objective)にもよりますが、EC2 Auto Recoveryを使うことでシングルインスタンスで稼働することができるかもしれません
  • ホットスタンバイ – 2つのアベイラビリティゾーンでX1インスタンスを稼働し、SAP HANAシステムレプリケーションによって予備インスタンスと同期することができます
  • ウォームスタンバイ / 手動フェイルオーバー – プライマリーのX1インスタンスとセカンダリーには永続ストレージが付与された小さなインスタンスで構成することもできます。フェイルオーバーが必要となった場合、セカンダリーインスタンスを停止し、インスタンスタイプをX1に変更し、再起動します。このユニークなAWSならではのオプションであれば、低コストを維持しながら、迅速な復旧が実現できます

今日のローンチにあわせてSAP HANA Quick Startを更新しています。新規のVPCもしくは既存のVPC内に、十分に検証済みのSAP HANAが1時間以内で利用可能です:

このクイックスタートは 、インスタンスと関連するストレージを構成し、SAP HANAと前提となるOSパッケージをインストールするのにお役立ちいただけます。

また、私たちはSAP HANA Migration Guideも公開しました。現行のオンプレミスもしくはAWS上で稼働するSAP HANAワークロードのAWSへの移行をお手伝いします。

Jeff;

翻訳はPartner SA 河原が担当しました。原文はこちらです。

AWS Config – タグの変更検知の高速化、新しいマネージド ルール追加、およびユーザビリティの向上

AWS Config Rulesにいくつかの改良が加わり、より便利に利用できるようになりました。”required-tags“ルールの精度が改善され、タグの変更後数分以内にタグ変更の通知を受け取ることができるよになりました。またIAMユーザに対する多要素認証が有効になっているかを確認するマネジドルールも新たに追加され、JavaのサンプルコードがConfig Rules GitHub レポジトリで公開されています。さらにConfig Rulesコンソールから準拠/非準拠の注釈を確認することができ、Config Rulesの詳細ページからルールの呼び出しであったり、評価の際のタイムスタンプ等より細かい粒度のステータスを受け取ることができるようになりました。

翻訳は酒徳が担当しました。原文はこちら