Amazon Web Services ブログ

週間 AWS – 2016 年 2 月 15 日

先週 AWS の世界で起こった出来事を振り返ってみましょう。

月曜日

2 月 15 日

火曜日

2 月 16 日

水曜日

2 月 17 日

木曜日

2 月 18 日

金曜日

2 月 19 日

土曜日

2 月 20 日

日曜日

2 月 21 日

注目すべき新しいオープンソース

  • aws-api-gateway-for-cloudformation は、 CloudFormation に対する API Gateway のサポートを可能にする一連のカスタムリソースです。
  • WaterFlow は、 Amazon Simple Workflow で使用するための、魔法のような簡単に理解できる JDK8 フレームワークです。
  • gnu-mailman-aws には、GNU Mailman を EC2 インスタンスにインストールして実行するプロセスが記載されています。
  • spa-aws は、AWS Lambda を使用するシングルページアプリケーションです。
  • petit は AWS で使用するために Ruby で開発された URL 短縮ツールです。
  • state-of-cloud は、クラウドのインベントリを一覧表示し、AWS や他のサービスの使用状況を報告するツールです。
  • aws-helpers は AWS 用の一連の Node.JS ヘルパーです。
  • aws-lambda-canary は AWS 上の Lambda サービスのための Canary プロジェクトです。
  • cookiecutter-lambder は、Lambder プロジェクトを作成するための cookiecutter テンプレートです。
  • aws は、AWS プロジェクトでの Racket サポートを可能にします。

新しい SlideShare プレゼンテーション

新たに掲載されたお客様事例

  • Change Healthcare – Change Healthcare は AWS を使用することによって、顧客向けの新しいサービスの迅速な開発およびテスト、大きなデマンドを満たすスケール性、IT のコストと複雑さの最小化を実現できます。
  • Dodge Data & Analytics – Dodge Data & Analytics は AWS を使用することによって、以前のインフラストラクチャに比べて 5,250,000 USD を節約できており、アプリのパフォーマンスを最大 50% 向上させています。
  • HOYA株式会社 – HOYA株式会社は、SAP Business Suite と災害対策環境を AWS に移行することにより、以前のプライベートクラウド環境に比べて IT コストを最大 60% 節約しています。
  • Inneractive – Inneractive は、パートナー Spotinst と協力して Amazon EC2 スポットインスタンスをセットアップすることにより、AWS の月次請求金額を 20~30% 節約しています。
  • Kik – Kik は AWS を使用することによって、可用性が高く、高速で応答性にすぐれたメッセージングサービスを提供しています。
  • AWS Partner Network Blog へのポスト

新しく投稿された YouTube 動画

近日開催のイベント

人材募集

次週をお楽しみに! それまでは、Twitter でフォローして、RSS フィードをサブスクライブしてね。

Amazon RDS Update – MySQL 5.7 のサポート

MySQL 5.7 を実行する Amazon RDS データベースインスタンスを起動できるようになりました。

このリリースの MySQL では、パフォーマンス、スケーラビリティ、およびセキュリティに関して多くの機能拡張が提供されています。最も重要で現実の問題に強く関連する機能拡張のいくつかを、次に示します。

  • JSON データと、次の組み込み JSON 関数のネイティブサポートJSON_ARRAYJSON_OBJECTJSON_QUOTEJSON_CONTAINSJSON_CONTAINS_PATHJSON_EXTRACTJSON_KEYSJSON_SEARCHJSON_APPENDJSON_ARRAY_APPENDJSON_ARRAY_INSERTJSON_INSERTJSON_MERGEJSON_REMOVEJSON_REPLACEJSON_SETJSON_UNQUOTEJSON_DEPTHJSON_LENGTHJSON_TYPE、および JSON_VALID
  • 新規および強化されたパフォーマンスメトリックスへのアクセスを提供するパフォーマンススキーマ
  • 解析、EXPLAIN、およびクエリの処理向上を実現するオプティマイザーの強化。
  • ネイティブ InnoDB 空間インデックスと Boost.Geometry との統合機能を備えた GIS (詳細については、「MySQL 5.7 and GIS, an Example」と「Making Use of Boost Geometry in MySQL GIS」を参照)。
  • 新しい論理クロックモードの使用による並列レプリケーションの強化 (詳細については、「Multi-threaded Replication Performance in MySQL 5.7」を参照)。
  • InnoDB のスケーラビリティと一時テーブルのパフォーマンスの強化。クラッシュ回復時のテーブルスペース検出と動的バッファプールリサイジングの強化。

詳細については、「MySQL 5.7 Release Notes」を参照してください!

データベースインスタンスの起動
他のインスタンスと同じように、これらのインスタンスは、AWS マネジメントコンソールAWS コマンドラインインターフェイス (CLI)AWS Tools for Windows PowerShell、RDS API (CreateDBInstance)、または CloudFormation テンプレートから起動できます。次に、コンソールからデータベースインスタンスを起動する方法を示します。

インスタンスを起動したら、セキュリティグループを編集して、使用している EC2 インスタンスのパブリック IP アドレスを含めます。次に、いつものように、そのアドレスに接続します。

新しいパフォーマンススキーマを簡単に確認します。

このデモでは、時間が限られており、使用している MySQL も陳腐なものですので、新しい機能はいずれも実行していません。これは、皆さんにお任せします。

すぐに利用できます
Amazon RDS for MySQL は、米国東部 (バージニア北部)米国西部 (北カリフォルニア)米国西部 (オレゴン)欧州 (アイルランド)欧州 (フランクフルト)アジアパシフィック (シンガポール), アジアパシフィック (シドニー), アジアパシフィック (東京), アジアパシフィック (ソウル), 中国 (北京)南米 (ブラジル)、および AWS GovCloud (米国) の各リージョンで利用できます。


Jeff

追記 – 多くの方から、バージョン 5.6 からバージョン 5.7 へのインプレースアップグレードについての問い合わせがありました。開発チームに問い合わせたところ、これは機能することが確認されました。開発チームは、できるだけ早急にバージョン 5.7 が利用できるようになることを切望しており、現在使用できる 2 つのアップグレードオプション (ダンプ & リロードまたはレプリカの読み込み) を推奨しています。

New – AWS CodeDeploy イベントの通知機能

AWS CodeDeploy は、EC2 インスタンスや オンプレミスで稼働するインスタンスを含む、さまざまなインスタンスに、それらを可能な限りオンライン状態にしたまま、コードを容易にデプロイできるようにするサービスです。CodeDeploy は、1 つのインスタンスから数千のインスタンスにいたる範囲を対象にできるように設計されました (詳細については、「New AWS Tools for Code Management and Deployment」を参照)。

CodeDeploy の通知
全体的なビルド、テスト、およびデプロイパイプラインの一環として、CodeDeploy を使いやすくするために、今日、新しい通知システムを導入しました。Amazon SNS 通知をアプリケーションのデプロイプロセスの前後および途中に送信するトリガーを作成できるようになりました。トリガーの設定は、デプロイプロセス全体を対象にすることも、デプロイプロセスでターゲットにされる個々のインスタンスを対象にすることもできます。また、成功した場合と失敗した場合の両方で、トリガーを送信できます。次に、すべてのトリガーを一覧します。

  • DEPLOYMENT_START
  • DEPLOYMENT_SUCCESS
  • DEPLOYMENT_FAILURE
  • DEPLOYMENT_STOP
  • INSTANCE_START
  • INSTANCE_SUCCESS
  • INSTANCE_FAILURE

アプリケーションあたり最大 10 のトリガーを作成できます。複数のトリガーを 1 つのトピックに接続することも、各トリガーを個々のトピックに送信することもできます。SNS でサポートされているいずれのデリバリプロトコル (httphttps、E メール、SMS、およびモバイルプッシュ) も使用できます。Lambda 関数を起動することもできます。

トリガーの作成
トリガーは、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (CLI) を介して作成できます。この投稿では、コンソールを使用する操作手順を示します。サンプル CodeDeploy アプリケーションをセットアップします (3 つの t2.micro インスタンス)。

次に、初期デプロイを実行します。

SNS トピックを作成し、E メール経由でサブスクライブして、サブスクリプションを確認します。

コンソールに戻り、CodeDeploy 内でアプリケーションを開きます。

別のタブで IAM を開き、サービスロールに関連付けられているポリシーに、SNS に書き込むアクセス許可を付与します (アプリケーション用にマネージド型 AWSCodeDeployRole を選択している場合は、これを行う必要はありません)。

CodeDeploy に戻り、[Create trigger] をクリックします。名前を入力し、イベントを選択し (この例ではすべてのイベントを選択)、ドロップダウンから SNS トピックを選択します。

また、個々のイベントも選択します。

トリガーが作成され、コンソールに表示されます。

CodeDeploy によって確認メッセージがトピックに送信され、[受信トレイ] の先頭に表示されます。

デプロイを開始し、E メールが届くのを待ちます。次のようなメッセージが届きます。

説明をわかりやすくするために E メールを使いましたが、実際のアプリケーションでは、メッセージを取得して処理するコードを記述する必要があります。

トリガーはすでに利用でき、すぐに使い始めることができます!

Amazon Aurora への移行 – お客様自身が語るサクセスストーリー

今回は、AWS のお客様である Safe Software によって記述されたゲストポストを紹介します。同社は Amazon Aurora のアーリーアダプターで、有用な経験をシェアしています。


Jeff


Safe Software はデータ移動のビジネスに携わっているので、先端のデータベーステクノロジーをサポートするように常に心がけています。この理念の当然の結果として、Amazon Aurora にも興味を抱きました。

AWS と Aurora のパワーを顧客のために活用するだけでなく、当社の内部プロセスを改善するという観点からも、この新しいテクノロジーを評価しました。Aurora のベータバージョンがリリースされたときに、当社のシステムを Aurora に移行することをすぐに考えました。この決定は、価値あるものであることが証明されました。Aurora に移行することによって、生産性が向上しただけでなく、年間のシステムコストが 40% も削減されました

すでに移行は終了しているので、この経験から得たヒントや洞察を、Aurora への移行を検討している人たちとシェアしたいと思います。移行作業の詳細について説明したいのですが、実際にはボタンをクリックするだけで終了してしまったので、多くを書くことはできません。その代わりに、私たちが最初に試したこと、準備に使った方法、Aurora での運用を開始した後でシステムをさらに最適化した方法について、シェアしようと思います。

クラウドを必要とした理由
当社では、当社の空間データ変換テクノロジー FME の高い品質を維持するために、厳しい自動化テストスイートを実行します。このプラットフォームは、365 を超えるデータフォーマットと制限のない変換をサポートするので、自動化された日々のテストは、15,000 のテストを、4 つのオペレーティングシステムと 3 つの製品で、24 時間 365 日実行、というようにとても厳しいものになっています。

問題は、システムの健全性を維持するための、ハードウェアのプロビジョニングを継続できないことです。1 秒という応答想定時間を維持できなくなった、などとは思わないでください。

当社の内部プロダクションデータベースは、きわめてトラフィックの多いシステムで、140 を超えるテーブルに 1 億行にも達するデータが格納されています。このデータベースは、内部のイントラネットとレポート処理のフレームワークと同様に、ビルドシステムとテストシステム用の主要な運用リポジトリであり、150 台に及ぶサーバーファームをサポートしています。100 人を超えるユーザーが、このシステムを頼りにしています。

Aurora の前に試したこと
私たちは当初、すべてを RDS 上の MySQL に移行しようと考えましたが、負荷を管理するために、リードレプリカをかなり大きなインスタンス上で実行する必要があることに気付きました。それでも、ほとんどのクエリ用に処理できる接続数の運用上限を引き上げようと悪戦苦闘しました。必要な応答時間を達成しようともがきました。しかし、このソリューションは、すぐにコストが倍に膨れ上がりました。

多くの時間を MySQL の習熟に費やしましたが、新しいシステムのすべてを再び学習しなければならないということは苦痛を伴いました。このような経験から、アプライアンスのように扱える何かがあれば、事態ははるかによくなることに気付きました。

フェイルセーフな準備と移行
Aurora が MySQL 経験を活かせると聞き、試す価値があると考えました。失うものが何もないことを確認するために、プロダクションシステムを既存の形態で稼働させながら、Aurora をテストすることに決めました。

パフォーマンスのより高いシステムに移行することの利点の 1 つは、数年前に戻ってシステムを再評価する良い機会を得られることです。この移行時には、いくつかのハウスキーピング処理を実行しました。データベースについて、インデックス、テーブル構造、および多くのその他のリレーショナルデータベースに関する側面を見直しました。また、ロジックをさらに簡素化するために、複数のスキーマを組み合わせて、わずか 2 つにすることができました。

Aurora への実際の移行作業自体は、簡単に終了しました。Amazon のコントロールパネルで、ボタンクリックによる移行を選択しました。移行はバッググラウンドで実行され、結果として、MySQL で実行されていたものが、Aurora 内にコピーとして作成されました。きわめて簡単でした!

カットオーバーを管理することは、スケジュールの面でかなり大きなことであり、運用に影響を及ぼさないようにしながら、データの最新のスナップショットをキャプチャする必要があります。私たちは同期がずれることを心配しました。つまり、移行が終了したときに、読み込みレプリカが古いデータのままになり、使うことができなくなるのではないかという心配がありました。プロダクションシステムを稼働させながら移行するのに数時間がかかり、この間にデータが変化する可能性があることがわかっていました。

移行をライブシステムで、そのシステムを稼働させながら深夜に行うことを選択しました。当社独自の FME 製品を活用して、移行時に揮発性テーブルで発生する変更をキャプチャし (総データの 2~3%)、ポーティングしました。

ビルドとリリースのチームは、移行を自分自身で管理でき、IT 部門が関与したのは、ID とアクセスの管理を構成することと、すべての準備が整ったことが確認された後でのネットワーク上の DNS の変更だけでした。

最初にいくつかのサンプルを使用してサニティチェックを行いましたが、私たちはアーリーアダプターだったので、手探り状態での試行が続きました。ただし、必要に場合には、古いシステムにロールバックできることを確信していました。

移行後の最適化
移行後にすべてのプロセスを徹底的にテストしました。最初の 2 日間の監視において、困惑するような出来事がいくつかありました。運用時に CPU 負荷が散発的に重くなり、Aurora がスローダウンすることがありました。このような現象は、以前の MySQL の運用時には検知されませんでした。

私たちはスローダウンを追跡して、深くネストされている SELECT を使用する非効率なクエリを見つけました。これらは簡単には修正できませんでした。これらの問題は、いくつかの単純なスキーマ変更を実施して解決し、複雑性の高い関係については、自社の製品である FME を使用して、事前に封じ込めることができました。重要なヒント – スキーマ設計は引き続き重要。

移行以来、その他の問題は発生せず、これらのクエリやインデックスのチューニングは、結果的にメリットをもたらしました。運用に関しては、これまで使ってきた慣れ親しんだインターフェイスを使用して、エンタープライズスケールで行っています。

ほとんどすべての運用に関して、Aurora はこれまでのシステムより高速であることが証明されており、はるかに高いレベルのスケーラビリティを提供しています。現在、比較的中規模のセットアップを実行しています。これは、拡張できることがわかっているからできることですが、こうすることで、年間約 8,000 USD を節約しています (コストが 60% 減少)。実際、Aurora を使うことでパフォーマンスは 2 倍になっていますが、コストは昨年よりも少なくなっています。また、年間運用向けにインスタンスをリザーブすることで、さらに 2,000 USD を節約しています。

運用管理はきわめて重要な要件ですので、バックアップやデータベース障害について心配しなくて済むのは、とても心休まることです。また、マネージド型データベースは、多くの頭痛の種も取り除いてくれました。このパフォーマンスを自分たちだけで達成しようとした場合、ハードウェアと人的資源に多大な投資が必要だったと思います。

Aurora を使用することで、当社の FME 製品ビルドを作成する作業がより良く、高速になり、テスト結果を迅速に入手できるようになりました。このことは、究極的には、これまでになく高いレベルの品質の製品を提供できるようになったことを意味します。

Iain McCarthy、Product Release Manager、Safe Software Inc.

 

 

Amazon EMR Update – EBS および M4 & C4 インスタンスタイプのサポート

同僚の Abhishek Sinha が Amazon EMR の最新の追加機能について記述したゲストポストを、以下に掲載します。


Jeff


Amazon EMR は、Apache HadoopApache SparkPresto などの分散データ処理フレームワークを使って、EC2 インスタンスのマネージドクラスター上のデータを処理することを可能にするサービスです。

新しいバージョンの EMR (3.10 および 4.x) では、Amazon EBS ボリュームを使用して、各インスタンスのローカルストレージを増やすことができます。これは、サポートされるインスタンスタイプの既存のセットですぐれた機能を発揮し、EMR で M4C4 のインスタンスタイプを使用することを可能にします。ここでは、これらの両方の機能について詳しく説明します。

Amazon EBS の使用によるインスタンスストレージの拡大
EMR は HDFS (Hadoop Distributed File System) 用に各インスタンスのローカルストレージを使用して、S3 からのデータを処理する際に EMRFS を使用して中間ファイルを保存します。このストレージを拡張するために、EBS ボリュームを使用できるようになりました。EBS ボリュームは、関連付けられているインスタンスのライフサイクルに結び付けられ、インスタンスの既存のストレージが増えます。クラスターが終了すると、関連付けられている EBS ボリュームも一緒に削除されます。

次のシナリオでは、EMR インスタンスのストレージをカスタマイズできる利点を活用できます。

  1. 処理要件として、インスタンスのデフォルトで利用できる HDFS (またはローカル) ストレージよりも多くのストレージが必要 – EBS ボリュームのサポートにより、インスタンスが提供するコンピューティング性能に応じて、インスタンスのストレージキャパシティーをカスタマイズできます。また、インスタンスのストレージを最適化することでコストを節約できます。
  2. M4、C4、R3 などの最新世代の EC2 インスタンスタイプのメリットを活用する必要があり、しかもこれらのインスタンスタイプで利用できるよりも多くのストレージが必要 – EBS ボリュームを追加してストレージをカスタマイズすることにより、ニーズをよりよく満たせるようになります。旧式の M1 や M2 のインスタンスを使用している場合、より新しい M4、C4、および R3 のインスタンスに移行することによって、コストを削減し、パフォーマンスを改善できます。お使いのアプリケーションのベンチマークテストを行い、特定のワークロードへの影響を計測することをお勧めします。

注意する必要がある点として、Amazon EMR クラスターに追加される EBS ボリュームでは、クラスターがシャットダウンするとデータが消滅するということがあります。EMR では、クラスターの終了時にボリュームは自動的にクリーンアップされます。

クラスターへの EBS ボリュームの追加
EMR では、現在、クラスター内のノードは 3 つの論理インスタンスグループにまとめられます。これらのグループとしては、YARN Resource Manager と HDFS Name Node サービスを実行するマスターグループ、HDFS DataNode デーモンと YARN Node Manager サービスを実行するコアグループ、および YARN Node Manager サービスを実行するタスクグループがあります。EMR では、クラスターごとに最大 50 のインスタンスグループがサポートされ、グループごとにインスタンスタイプを選択できます。特定のインスタンスグループの各インスタンスに追加する EBS ストレージのサイズを指定できるようになりました。複数の EBS ボリュームの指定、インスタンスストレージのあるインスタンスへの EBS ボリュームの追加、さらには、異なるタイプの異なるボリュームの組み合わせを行うことができます。次に、EMR コンソールでストレージ構成を指定する方法を示します。

例えば、コアグループとして、m4.2xlarge インスタンスを使用し、1 ペアの 1 TB gp2 (汎用 SSD) ボリュームをアタッチし、グループ内に 10 のインスタンスが存在するように構成して、結果として、コアグループには、10 のインスタンスと合計 20 ボリュームが存在するようにします。次の図に、このセットアップの例を示します。

詳細については、EBS の「よくある質問」を参照してください。 EBS のサポートは、AMI 3.10 および EMR リリース 4.0 から利用できます。

EBS ボリュームのパフォーマンス特性
Amazon EMR では、汎用 SSD (GP2)、マグネティック、プロビジョンド IOPS (SSD) の 3 つの異なる EBS ボリュームタイプが利用できます。使用するボリュームのタイプは、ジョブの特性に応じて選択できます。当社の内部テストでは、汎用 SSD ボリュームはほとんどのワークロードの要件を満たすことが示されていますが、お客様においては、自身のワークロードを使用してテストすることが推奨されます。注目すべき点として、汎用 SSD ボリュームは基準パフォーマンスとして 3 IOPS/GiB (最大 10,000 IOPS) を備えており、バースト時には 1,000 GiB 以下のボリュームで 3,000 IOPS を達成します。詳細については、「I/O クレジットおよびバーストパフォーマンス」を参照してください。次の表に、ボリュームタイプごとのパフォーマンス特性を示します。

汎用 (SSD) プロビジョンド IOPS マグネティック
ストレージメディア  SSD タイプ  SSD タイプ  磁気タイプ
最大ボリュームサイズ  16 TB  16 TB  1 TB
ボリューム当たりの最大 IOPS  10,000 IOPS  20,000 IOPS  ~100 IOPS
最大 IOPS バーストパフォーマンス  3000 IOPS (1 TB 以下のボリューム時)  該当なし  数百
ボリューム当たりの最大スループット 160 MB/秒  320 MB/秒  40~90 MB/秒
最大 IOPS/ノード (16K)   48,000  48,000  48,000
最大スループット/インスタンス 800 MB/秒  800 MB/秒  800 MB/秒
レイテンシー (ランダム読み取り)   1~2 ms  1~2 ms  20~40 ms
API 名  gp2  io1  スタンダード

M4 および C4 のインスタンスのサポート
M4 および C4 のインスタンスが利用可能なリージョンで、それらのインスタンスを使用する EMR クラスターを起動できるようになりました。M4 インスタンスは、独自の Intel Xeon E5-2676 v3 (Haswell) プロセッサで動作し、C4 インスタンスは、Intel Xeon E5-2666 v3 プロセッサで動作します。これらのインスタンスは、EC2 で最高レベルのプロセッサパフォーマンスを提供するように設計されています。両方のタイプのインスタンスは、拡張ネットワーキングをサポートします。拡張ネットワーキングは、それが無効な場合に比べて最大 4 倍のインスタンスパケットレートを達成します。さらに、高ネットワーク I/O の状況下でも一貫したレイテンシーを維持します。M4 と C4 の両方のインスタンスは、デフォルトで EBS 最適化されており、I/O 操作用に専用のネットワークキャパシティーが追加されています。これらのインスタンスは、64 ビット HVM AMI をサポートし、VPC 内でのみ起動できます。

これらのインスタンスの料金の詳細については、Amazon EMR の「料金」ページを参照してください。

生産性向上に役立つヒント
EBS ボリュームを含む既存の EMR 4.x クラスターの構成を作成する create-cluster コマンドを生成できます。コマンドを生成することで、AWS コマンドラインインターフェイス (CLI) を使用して、クラスターを再作成できるようになります。

すぐに利用できます
これらの新機能はすでに利用可能であり、すぐに使用を開始できます。

Abhishek Sinha、シニア製品マネージャー

 

 

 

週刊AWS – 2016年2月8日

 

先週AWSの世界で起こった出来事を振り返ってみましょう。
※東京リージョンで提供していないサービスが含まれています。ご利用の際にご確認ください。

月曜日

2月8日

火曜日

2月9日

水曜日

2月10日

木曜日

2月11日

金曜日

2月12日

Jeff; (翻訳は石橋が担当しました。原文はAWS Week in Review – February 8, 2016

 

 

 

 

Parse アプリケーションを AWS に移行するためのリソース

 

Parse アプリケーションを AWS に移行するためのリソース Parse の段階的終了に関する最近の発表を踏まえ、AWS チームは、AWS コミュニティのメンバー向けに、いくつかの移行パスと代替サービスを開発者に提供するべく取り組んできました。ここでは、現在把握している情報をご紹介します。

  • AWS Mobile Development Blog の新しい投稿で、Parse Push から Amazon SNS への移行の方法を説明しています。 この投稿では、Parse からのデータのエクスポート、APNS および GCM の認証情報の取得、AWS リソースおよび Mobile Hub プロジェクトの作成、データのインポート、Amazon SNS トピックのパブリッシュと購読を実行するためのコードの修正というプロセスを説明しています。
  • MongoDB on the AWS Cloud Reference Deployment では、AWS で MongoDB クラスターを設計してホストする方法を説明しています。将来 Parse プラットフォームから移行することを決定した場合は、モバイルアプリケーション用の高速でスケーラブルな NoSQL データベースバックエンドとして Amazon DynamoDB を使用できます。
  • How to Set up Parse Server on AWS Using AWS Elastic Beanstalk という新しい投稿で、Parse サーバーを含む環境をセットアップする方法を説明しています。MongoLab (ホストされたバージョンの MongoDB) を使用するか、前述のリファレンスドキュメントを使用して独自にセットアップすることができます。
  • Transition Guide: Parse Analytics to Amazon Mobile Analytics という別の新しい投稿では、Amazon Mobile Analytics を使用してアプリケーションの使用量と収益を測定する方法を説明しています。
  • いずれかの Parse デバイス SDK を使用してモバイルデバイスで動作する IoT スタイルのコードを記述した場合は、そのコードを AWS IoT サービスに移行できます。Welcome Parse IoT Customers という新しい投稿で、その方法を説明しています。
  • AWS Mobile Hub を使用すると、さらに短時間でモバイルアプリケーションを構築できます。詳細については、AWS Mobile Hub – Build, Test, and Monitor Mobile Applications という投稿を参照してください。

また、パートナーおよびコミュニティのリソースをいくつかご紹介します。

移行に関するオンラインセミナー当社の John Bury (プリンシパルソリューションアーキテクト) は 12 年以上にわたりモバイル分野に携わってきました。 その Bury が 3 月 1 日に、Migrating Mobile Apps from Parse to AWS という 200 レベルのオンラインセミナーを実施します。 このオンラインセミナーは午前 11 時から正午まで (太平洋標準時) です。AWS モバイルサービス全般について紹介した後で、Parse から AWS にモバイルアプリケーションを移行するために必要な手順を説明します。

 

 

アマゾン ウェブ サービスが NICE を買収

 

NICE を新しい同僚として暖かく迎えたいと思います。当社は、ハイパフォーマンスなテクニカルコンピューティングのためのソフトウェアとサービスを提供する主要プロバイダーである同社を買収することに合意しました。

HPC 向け製品
イタリアのアスティに本社を置く NICE は、世界中のお客様に製品とソリューションを提供しています。これらの製品は、ハイパフォーマンスコンピューティング (HPC) およびビジュアライゼーションのワークロードの最適化と集約に役立つと同時に、モバイルデバイスを利用する分散環境の従業員にとって有用なツールも提供します。

既存のお客様への対応
NICE のブランドとチームはそのまま、EnginFrame および Desktop Cloud Visualization (DCV) 製品の開発をサポートを継続します。お客様は引き続き、AWS チームの支援により強化された世界最高レベルのサポートとサービスを受けることができます。NICE と AWS は今後、協力してさらに優れたツールとサービスを生み出していきます。

毎日が初日
ジェフ・ベゾス がよく言うように、私たちにとって毎日が初日であり、まだすべての答えが見つかってはいないのです。しかし、このニュースを皆様にお知らせし、新しい同僚と顔を合わせて共に働けることを楽しみにしているとお伝えしたいと考えました。この契約は 2016 年第 1 四半期中に成立すると予想しています。

 

 

最新情報 – Lambda 関数から VPC 内のリソースへのアクセス

 

数か月前に、AWS Lambda 関数から VPC 内のリソースにまもなくアクセスできるようになると発表しました。要望の多かったこの機能が提供開始され、今日からご利用いただけることをお伝えできて嬉しく思います。

今回、Lambda 関数から Amazon Redshift データウェアハウス、Amazon ElastiCache クラスター、Amazon Relational Database Service (RDS) インスタンス、および特定の VPC 内からのみアクセス可能だったサービスエンドポイントにアクセスできるようになりました。それには、お使いの VPC を 1 つ選択し、関連するサブネットとセキュリティグループを指定するだけです。Lambda はこの情報を使用して、Lambda 関数が VPC 内のリソースにサクセスできるように、Elastic Network Interface (ENI) および (指定したサブネットから取り出された) プライベート IP アドレスをセットアップします。

VPC 内のリソースへのアクセス
これは新しい関数を作成するときにセットアップできます。また、既存の関数が VPC にアクセスできるように更新することもできます。この機能は、Lambda コンソールまたは CLI から設定できます。 ここでは、コンソールからセットアップする方法を説明します。

必要な設定はこれだけです。不明点がある場合は、Lambda ドキュメントの「Configuring a Lambda Function to Access Resources in an Amazon VPC」をお読みください。

知っておくこと
この新機能について知っておいていただきたいことがいくつかあります。

ENI と IP アドレスのリソース – Lambda は、処理の必要があるイベント数に基づいて自動的にスケールするため、ご使用の VPC では、指定したサブネットで空き IP アドレスが適切に提供される必要があります。

インターネットアクセス – 特定の関数に対してこの機能を有効にすると直ちに、その関数はデフォルトではインターネットにアクセスできなくなります。関数でこのタイプのアクセスが必要な場合は、ご使用の VPC でマネージド NAT ゲートウェイをセットアップするか (詳細については New – Managed NAT (Network Address Translation) Gateway for AWS を参照)、独自の NAT を実行する (「NAT インスタンス」を参照) 必要があります。

セキュリティグループ – 関数に対して選択するセキュリティグループにより、サブネット内およびインターネット上のリソースへの関数のアクセスが制御されます。

S3 エンドポイント – この機能を使用して VPC 内の S3 エンドポイントにアクセスすることもできます (詳細については New – VPC Endpoint for Amazon S3 を参照)。

オンラインセミナー – この新機能について詳しく知りたい場合は、今後予定されるオンラインセミナー Essentials: Introducing AWS VPC Support for AWS Lambda にご参加ください。

 

 

Amazon RDS の更新 – 暗号化されたスナップショットの共有、既存のインスタンスの暗号化

 

Amazon RDS の更新 – 暗号化されたスナップショットの共有、既存のインスタンスの暗号化 当社では、ご使用の AWS 環境をできるだけ簡単に保護できるようにしたいと考えています。この分野での最近の発表には、暗号化された EBS ブートボリュームAmazon Aurora での保管時の暗号化、複数の異なるサービスにわたる AWS Key Management Service (KMS) のサポートがありました。今日は、Amazon Relational Database Service (RDS) に保存されたデータに関するいくつかの追加オプションについて説明します。暗号化されたデータベーススナップショットを他の AWS アカウントと共有できるようになりました。また、暗号化されていないデータベースインスタンスに暗号化を追加することも可能になりました。暗号化されたスナップショットの共有 データベースインスタンスに対して保管時の暗号化を使用すると、インスタンスから自動および手動で作成されたデータベーススナップショットも暗号化されます。これまで、暗号化されたスナップショットは単一の AWS アカウントでのみ使用可能で、共有はできませんでした。今回、暗号化されたスナップショットを最大 20 の別の AWS アカウントと共有する機能を提供します。これを行うには、AWS Management ConsoleAWS Command Line Interface (CLI)RDS API のいずれかを使用します。暗号化されたスナップショットは AWS リージョン内で共有できますが、パブリックで共有することはできません。既存の共有機能と同様に、今回のリリースは手動作成のスナップショットに適用されます。暗号化されたスナップショットを共有するには、スナップショットを選択して Share Snapshot をクリックします。これにより Manage Snapshot Permissions ページが開きます。1 つ以上のアカウント ID を入力し (1 つ入力するごとに Add をクリック)、すべて入力したら Save をクリックします。

アカウントは、自社が所有するもの (たとえば開発用、テスト用、ステージング用、本番用に個別のアカウントがある場合) またはビジネスパートナーが所有するものを指定できます。重要なデータベースを別の AWS アカウントにバックアップするのがベストプラクティスですが、この新機能を使用して実装できると同時に、保管時の暗号化のメリットも享受できます。

Save をクリックすると、他のアカウントが共有スナップショットにアクセスできるようになります。それらのアカウントを特定する最も簡単な方法としては、RDS コンソールにアクセスし、Shared with Me を使用してリストをフィルタします。スナップショットは、新しい RDS データベースインスタンスを作成するのに使用できます。 詳細については、「DB スナップショットの共有」を参照してください。 既存のデータベースインスタンスへの暗号化の追加 KMS キーを使用して、暗号化されていないデータベースインスタンスに保管時の暗号化を追加できるようになりました。これは、複数のステップから成るシンプルなプロセスです。

  1. 暗号化されていないデータベースインスタンスのスナップショットを作成します。
  2. このスナップショットを、新規の暗号化されたスナップショットにコピーします。暗号化を有効にし、任意の KMS キーを指定します。
  3. 暗号化されたスナップショットを新規のデータベースインスタンスにリストアします。
  4. 新しいデータベースインスタンスのエンドポイントを参照するように、アプリケーションを更新します。

これで必要な作業は終わりです。同様の手順で、既存のデータベースインスタンスの暗号化キーを変更できます。詳細については、「DB スナップショットのコピー」を参照してください。