Amazon Web Services ブログ

Amazon Kinesis Data Generatorを使用してストリーミングデータソリューションをテストする

by AWS Japan Staff | on 11 MAY 2017 | in Amazon Kinesis | Permalink

ストリーミングデータソリューションを構築する場合、ほとんどのお客様は、本番データと同様のデータを使用してストリーミングデータソリューションをテストしたいと考えています。この、データを作成してソリューションにストリーミングすることは、ソリューションをテストする際の最も退屈な作業かもしれません。

Amazon Kinesis StreamsとAmazon Kinesis Firehoseを使用すると、数十万のソースから1時間にテラバイト級のデータを連続的に捉えて保存できます。 Amazon Kinesis Analyticsでは、標準SQLを使用してリアルタイムでこのデータを分析および集計することができます。 AWS Management Console（またはAWS CLIまたはAmazon Kinesis APIを使用したいくつかのコマンド）で数回クリックするだけで、Amazon KinesisストリームまたはFirehose配信ストリームを簡単に作成できます。ただし、テストデータの連続したストリームを生成するには、AWS SDKまたはCLIを使用してAmazon Kinesisにテストレコードを送信することで、連続して実行されるカスタムプロセスまたはスクリプトを作成する必要があります。この作業はソリューションを適切にテストするために必要ですが、複雑さと開発時間とテスト時間が長くなることを意味します。

テストデータを生成してAmazon Kinesisに送信するユーザーフレンドリーなツールがあれば素晴らしいとは思いませんか？そこで、Amazon Kinesis Data Generator（KDG）の出番です。

(more…)

GTC 2017にてAWSとNVIDIAは深層学習のパートナーシップを拡大させました

by AWS Japan Staff | on 11 MAY 2017 | in Amazon EC2, Apache MXNet, Deep Learning | Permalink

今年のNVIDIAのGPU Technology Conferenceにて、AWSとNVIDIAはいくつかのイニシアチブにおいてパートナーとなりました。1つ目はとてもワクワクしている最新のVoltaベースのGPUインスタンスで、LSTMの学習が3倍高速になるように、AI開発者が接する世界を完全に別物にしてしまうと我々は考えています。2つ目は、AWSで動いているDeep Learning Institute (DLI)を通じて10万人以上の開発者をトレーニングする計画を発表しました。3つ目として、広い開発者コミュニティのために深層学習を大規模にスケール可能とするツールの共同開発です。

GTCでAWSは複数のセッションを行っており、Apach MXNetを使ってAmazon EC2のP2インスタンス上で学習をスケールさせたり、NVIDIAのJetson TX2 platformを使ってエッジ上でモデルを動かしたりしています。以下が今回の重要なパートナーシップと素晴らしいイノベーションの内容になります！

Volta – インスタンスとしてあなたの側にやってくる

Tesla V100はVoltaアーキテクチャベースで640のTensor Coreを備え、混合精度の深層学習において120テラフロップスという素晴らしいパフォーマンスを提供します。AWSはV100をAmazon EC2インスタンス上でサポートできるということに非常にワクワクしています。このサポートが意味するところは、成長しつづける深層学習のコミュニティがスパコン級の能力を活かしてより深いモデルを学習し、AIの限界を押し広げることができるということです。また、NVIDIAとのコラボレーションによって、AWSのエンジニアと研究者はApache MXNetのNeural machine translation (NMT)アルゴリズムを先行して最適化することができました。これによって開発者はVoltaベースのプラットフォーム上で可能な最も速い手法で学習をすることができます。まとめると、Voltaベースのインスタンスが開発者にとってとても人気のあるものになると期待しています！

深層学習を世界中の10万人以上の開発者に届ける

NVIDIAとパートナーとなって、AWS上でDeep Learning Instituteのコースを提供できることを嬉しく思います。DLIは、自動運転車、ヘルスケア、ウェブサービス、ロボティクス、動画分析、そして金融サービス等のための深層学習の応用利用をカリキュラムに含める様に拡大しています。カリキュラムには、講師主導のセミナー、ワークショップ、そして講座が含まれ、アジア、ヨーロッパ、アメリカに渡る開発者にリーチしようとしています。AWSのグローバルインフラストラクチャは42のアベイラビリティゾーン(8つの追加が計画中)と16のリージョン(3つがさらに計画中)を持っているので、AWSは多様な開発者達にリーチするのに最適なインフラストラクチャプラットフォームであります。

深層学習の人達に簡単な利用とスケールを届ける

昔は、深いネットワークを学習するために必要なレベルのパフォーマンスを得るためには、国立の研究所にあるスーパーコンピュータにアクセスする必要がしばしばありました。また、それを使うにはmessage passing interface (MPI)といった分散コンピューティングライブラリを理解して、複数のライブラリやいくつか依存するパッケージをセットアップできることが要求されました。スケーラブルな深層学習を開発者にとって簡単に使えるようにするというゴールに集中するために、AWSはNVIDIAとパートナーとなって最適化された開発者ツールを作ることにしました。これらのツールは、cuDNN、NCCL、TensorRT、そしてCUDA toolkitといったNVIDIA Deep Learning SDKライブラリを使ってビルドされています。開発者がこれらのツールを使うことで、もっと簡単に大量のGPUを数千万インスタンス時間規模でほとんどオーバーヘッドなくスケールできるということを見てきています。

クラウドからエッジへ深層学習を持ち込むためにコラボレーション

低電力デバイス上でのエッジの深層学習は、今日の深層学習の最も大きいトレンドの1つになります。レイテンシを抑えらることや、ネットワーク可用性のためのデータ局所性等、エッジにあるデバイス上でモデルを実行したい理由はたくさんあります。今週のGTCのAWSセッションにおいて、我々はP2インスタンス上で最新のモデルをどのように学習できるかをお見せします。また、最先端の人工知能の能力を低電力デバイスに持ち込むために、Jetson TX2 platformを含む多様な低電力デバイス上にどれだけ簡単にそのモデルをデプロイできるかもお見せしました。そして、AWS IoTやAWS Greengrassといったサービスを通じてこれらのデバイスを管理することができるので、end-to-endのAIワークフローを提供することができます。

さらに学ぶには

GTCのAWS深層学習セッションをご確認下さい
AWS Marketplace上のAWS Deep learning AMIを使って、今すぐ始めましょう

原文: AWS and NVIDIA Expand Deep Learning Partnership at GTC 2017 (翻訳: SA岩永)

AWS Batch上で深層学習

by AWS Japan Staff | on 11 MAY 2017 | in Amazon ECS, AWS Batch, Deep Learning | Permalink

同僚のKiuk ChungがAWS Batchを使って深層学習をするという素晴らしい記事を書いてくれました。

GPUインスタンスは当然のように深層学習とペアになりますが、それはそのニューラルネットワークのアルゴリズムがGPUインスタンスの超並列処理能力を活かすことができるからです。AWSではg2やp2といったGPUインスタンスを提供しており、お客様はスケーラブルなGPUワークロードを実行することができます。AWS Batchを使うことでそのスケーラビリティをもっと効率よく使うことができます。(訳注: 丁度GTC 2017のKeynoteにて次期NVIDIA GPUであるV100に関する情報も発表されましたのでご参考頂ければ幸いです: AWS and NVIDIA Expand Deep Learning Partnership at GTC 2017)

AWS Batchは皆さんの代わりに下回りの計算リソースを管理してくれるので、リソース管理のオーバーヘッド無しにモデリングすることに集中できます。AWS Batchにおける計算環境 (すなわちクラスタ)とは、皆さんのアカウント内のインスタンスのプールであり、AWS Batchはジョブの数に応じてインスタンスを起動したり削除したりしながらそれを動的にスケールしてくれます。これによって無駄なインスタンスを最小化でき、コストを最適化することができます。

さらに、AWS Batchは登録されたジョブが適切なインスタンスに配置されるように確実にスケジュールしてくれるので、ジョブのライフサイクルが管理されます。お客様独自のAMI利用の機能追加によって、AWS Batchの利用者はGPUが必要とされるジョブのためにもこの弾力性や利便性を活用することができるようになりました。

この記事ではGPUベースの深層学習ワークロードをAWS Batch上でどのように動かせばよいかをお見せします。Apache MXNetを使ってMNISTデータセットから手書きの数字を認識するための、畳み込みニューラルネットワーク(LeNetアーキテクチャ)の学習を例として使います。

MXNetのジョブをAWS Batchで実行する

Apache MXNetは機能が豊富で、柔軟にプログラムが書け、高いスケーラビリティをもった深層学習フレームワークで、畳み込みニューラルネットワーク (CNNs)やlong short-term memory networks (LSTMs)を含む最新の深層モデルをサポートしています。

AWS Batchでジョブを実行するには3つのステップがあります:

カスタムAMIを作成
AWS Batchのリソースを作成
学習ジョブを登録

カスタムAMIを作成

まず、NVIDIAドライバとAmazon ECSエージェントを含むAMIを作成するところから始めます。AWS Batchでは、計算環境を作成する時にimage_idを指定することで特定のAMIからインスタンスを起動させることができます。GPUが必要なジョブを実行しようとしているので、NVIDIAドライバが含まれたAMIが必要となります。

Launch Stackを選択して、あなたのアカウント上でus-east-1にCloudFromationテンプレートを起動します:

下にある様に、CloudFormationスタックのOutputsタブの中にあるAMIという値をメモしておきます。次のセクションで計算環境を作成する時にこれをimage_idの値として使います。

または、AWS BatchのドキュメンテーションのGPU有効なAMIを作成するに従っても良いです。

AWS Batchのリソースを作成

AMIを作成したら、以下のリソースを作成します:

計算環境は、同じまたは異なるインスタンスタイプのインスタンス(計算リソース)の集合です。ここでは、p2.xlargeのインスタンスを使ったマネージド計算環境を作成します。imageIdには、前のセクションで作成したAMIを指定します。

そうしたら、ジョブキューを作成します。AWS Batchでは、ジョブは計算環境の順序付きリストに紐付いたジョブキューに登録されます。順位が優先の計算環境が埋まってしまったら、ジョブは次の順位の計算環境へと漏れていきます。今回の例ではジョブキューには1つの計算環境のみ紐付けます。

最後に、ジョブの仕様のテンプレートとなるジョブ定義を作成します。Amazon ECSに馴染みのある方には、これはタスク定義と似たようなものですと言えばお分かりでしょう。ホスト上のNVIDIAドライバが含まれるディレクトリをコンテナの/usr/local/nvidia上にマウントします。またコンテナのプロパティでprivilegedフラグを設定する必要もあります。

以下のコードは前述のAWS Batchのリソースを作成してくれます。より詳しい情報は、AWS Batchユーザガイドをご覧ください。

git clone https://github.com/awslabs/aws-batch-helpers
cd aws-batch-helpers/gpu-example

python create-batch-entities.py\
 --subnets <subnet1,subnet2,…>\
 --security-groups <sg1,sg2,…>\
 --key-pair \
 --instance-role \
 --image-id \
 --service-role

学習ジョブの登録

ここまできたら、手書き数字の認識のための畳み込みニューラルネットワークモデルを学習するジョブを登録します。Amazon ECSのタスクの様に、AWS BatchではジョブはDockerコンテナ内のコマンドとして実行されます。MXNetを深層学習ライブラリとして使うためには、MXNetが含まれたDockerイメージが必要になります。ここではmxnet/python:gpuを利用します。

submit-job.pyスクリプトはジョブを登録し、CloudWatch Logsから出力をtailしてくれます。

# cd aws-batch-helpers/gpu-example
python submit-job.py --wait

下のような出力を見ることができると思います:

Submitted job [train_imagenet - e1bccebc-76d9-4cd1-885b-667ef93eb1f5] to the job queue [gpu_queue]
Job [train_imagenet - e1bccebc-76d9-4cd1-885b-667ef93eb1f5] is RUNNING.
Output [train_imagenet/e1bccebc-76d9-4cd1-885b-667ef93eb1f5/12030dd3-0734-42bf-a3d1-d99118b401eb]:
 ================================================================================

[2017-04-25T19:02:57.076Z] INFO:root:Epoch[0] Batch [100]	Speed: 15554.63 samples/sec Train-accuracy=0.861077
[2017-04-25T19:02:57.428Z] INFO:root:Epoch[0] Batch [200]	Speed: 18224.89 samples/sec Train-accuracy=0.954688
[2017-04-25T19:02:57.755Z] INFO:root:Epoch[0] Batch [300]	Speed: 19551.42 samples/sec Train-accuracy=0.965313
[2017-04-25T19:02:58.080Z] INFO:root:Epoch[0] Batch [400]	Speed: 19697.65 samples/sec Train-accuracy=0.969531
[2017-04-25T19:02:58.405Z] INFO:root:Epoch[0] Batch [500]	Speed: 19705.82 samples/sec Train-accuracy=0.968281
[2017-04-25T19:02:58.734Z] INFO:root:Epoch[0] Batch [600]	Speed: 19486.54 samples/sec Train-accuracy=0.971719
[2017-04-25T19:02:59.058Z] INFO:root:Epoch[0] Batch [700]	Speed: 19735.59 samples/sec Train-accuracy=0.973281
[2017-04-25T19:02:59.384Z] INFO:root:Epoch[0] Batch [800]	Speed: 19631.17 samples/sec Train-accuracy=0.976562
[2017-04-25T19:02:59.713Z] INFO:root:Epoch[0] Batch [900]	Speed: 19490.74 samples/sec Train-accuracy=0.979062
[2017-04-25T19:02:59.834Z] INFO:root:Epoch[0] Train-accuracy=0.976774
[2017-04-25T19:02:59.834Z] INFO:root:Epoch[0] Time cost=3.190
[2017-04-25T19:02:59.850Z] INFO:root:Saved checkpoint to "/mnt/model/mnist-0001.params"
[2017-04-25T19:03:00.079Z] INFO:root:Epoch[0] Validation-accuracy=0.969148

================================================================================
Job [train_imagenet - e1bccebc-76d9-4cd1-885b-667ef93eb1f5] SUCCEEDED

実際には、学習されたモデル情報をAmazon S3に保存することで後続の予測ジョブが学習したモデルを使って予測を生成できるように、ジョブのコマンドを修正したくなると思います。Amazon S3のオブジェクトをジョブからどのように参照するかについては、Creating a Simple “Fetch & Runb” AWS Batch Jobの記事をご覧ください。

まとめ

この記事では、MXNetを深層学習のライブラリとして使いながらAWS Batch上でGPU有効なジョブを実行する例をお見せしました。AWS Batchはご自身のワークロードのために最も最適なアルゴリズムを実装することに集中できるだけの基礎的な部分を提供してくれます。登録したジョブのライフサイクルを管理し、指定した範囲内でジョブの要求に合わせて動的にインフラを最適化することが可能です。コスト最適なやり方でAWSが提供する計算用インスタンスの水平スケーラビリティの利点を簡単に活かすことができます。

MXNetは、一方で、自身の深層学習アルゴリズムを実装し始めるために必要な、高度に最適化されスケーラブルなビルディングブロックを豊富に提供しています。これによって巨大なニューラルネットワークモデルを必要とする問題を解決するだけでなく、Amazon EC2の無制限の計算リソースをつなげることで繰り返しの時間を削減することもできます。

AWS Batchが皆さんの代わりにリソースを管理してくれるので、ハイパーパラメータの最適化のために数十、数百の検索を並列で実行して、問題に最適なモデルパラータを探すといったワークロードの実装を簡単に行うことができます。さらに、ジョブはDockerコンテナの中で実行されるので、必要に応じて最適なツールとライブラリを選択し、Dockerイメージをビルドし、好きなイメージを使ってジョブを登録することができます。

ご自身の手でこれを試してみることをおすすめします。そして感想をぜひ教えて下さい！

原文: Deep Learning on AWS Batch (翻訳: SA岩永)

Amazon CloudWatch LogsとMonologを使用したPHPアプリケーションログ

by AWS Japan Staff | on 10 MAY 2017 | in Amazon CloudWatch, Log, PHP | Permalink

ロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。今回の例では、PHPアプリケーションからのログを、Amazon CloudWatch Logsに出力させます。これを実現するために、すでに普及しよく利用されている標準に準拠した既存のソリューションを使いたいと思っていました。これらの理由からオープンソースのログライブラリであるPHP Monolog（https://github.com/Seldaek/monolog）を使用します。

PHP Monolog

新しいPHPアプリケーション、フレームワーク、またはサービスを扱う人にとって、ソリューション間で頻繁に現れる技術の選択肢の1つとしてアプリケーションログ用のMonologを利用することが挙げられます。PHP Monologは標準に準拠したPHPライブラリで、開発者はデータベース、ファイル、ソケット、さまざまなサービスなどのさまざまな種類のフォーマットにログを送信できます。PHP MonologはPSR-3で定義されたPHPロギングの標準化よりも前に、PSR-3のインターフェースと標準を実装していました。これにより、Monologはロギングライブラリ用の共通インタフェースに準拠しています。CloudWatch LogsでMonologを使用すると、PSR-3互換ロギングソリューションが作成されます。Monologは、Laravel、Symfony、CakePHPなど多くの異なるアプリケーションやフレームワークで使用できます。今日の例は、アプリケーションログの目的で、PHP Monologを使用してCloudWatchLogsに情報を送信し、CloudWatchのアラームと通知でアプリケーションデータを使用できる構造とプロセスを構築することです。これにより、アプリケーションからのログをキーにAmazon EC2 AutoScalingのようなサービスのアクションに使用することができます。

Amazon CloudWatch Logs

顧客第一主義の組織として、AWSはお客様やAWSパートナーが要望する重要な機能やサービスを絶えず構築し、リリースしています。本日、ハイライトされるサービスの1つがAmazon CloudWatch Logsです。CloudWatch Logsを使用すると、アプリケーション、オペレーティングシステムおよびインスタンス、AWSサービス、およびその他のさまざまなソースからのログファイルの情報を保存できます。以前のブログ記事では、CloudWatch Logsをさまざまなプログラミング例とともに紹介しました。

ブログ記事にはCloudWatch Logsを使用してアプリケーションからのエントリを保存するPHPの例があります。この例を使用してスタンドアロンソリューションとして拡張し、アプリケーション内からCloudWatch Logsにログを送ることができます。この例では、PHP Monologを活用してこの機能を強化します。

Monologの実装

Monologを使用開始するには、Composer(https://getcomposer.org/)を使用して必要なライブラリをインストールします。以下の手順では、AWS SDK for PHP、PHP Monologおよび CloudWatch Logsへのログを有効にするMonologのアドオンをインストールします。

curl -sS https://getcomposer.org/installer | php 
php composer.phar require aws/aws-sdk-php 
php composer.phar require monolog/monolog 
php composer.phar require maxbanton/cwh:^1.0

あるいは、次のエントリをcomposer.jsonファイルにコピーし、php composer.phar installコマンドでインストールすることもできます。

{
    "minimum-stability": "stable",
    "require": {
        "aws/aws-sdk-php": "^3.24",
        "aws/aws-php-sns-message-validator": "^1.1",
        "monolog/monolog": "^1.21",
        "maxbanton/cwh": "^1.0"
    }
}

Local logging

PHP Monologが利用できるようになったので、それを実装しテストすることができます。まず、1ファイルにロギングする例を示します。

require "vendor/autoload.php";

use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;

$logFile = "testapp_local.log";

$logger = new Logger('TestApp01');
$formatter = new LineFormatter(null, null, false, true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);
$logger->pushHandler($infoHandler);
$logger->info('Initial test of application logging.');

前の例では、先ほどインストールしたコンポーザーライブラリが必要です。新しいロガーラインは「TestApp01」として、チャンネル名を設定します。次の行は、未使用のログ項目の括弧を削除する新しいLineFormatterを作成します。次の行は、識別されるファイル名として先を確立しtestapp_local.log、およびINFOログレベルでそれを関連付けます。次に、ストリームハンドラにフォーマットを適用します。次に、更新された形式のストリームハンドラをハンドラリストに追加します。最後に、INFOというログレベルで新しいメッセージが記録されます。ログレベルとハンドラの詳細については、Monolog GitHubページとIETF RFC 5424およびPSR-3を参照してください。

機能を確認するために、ログファイルの内容を表示できるようになりました:

Syslog logging

シンプルなログエントリをローカルファイルに書き込むことができたので、次の例ではシステムのSyslogを使用してイベントを記録しています。

$logger = new Logger($appName);

$localFormatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);

$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($localFormatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);

$logger->info('Test of PHP application logging.');
$logger->warn('Test of the warning system logging.');

syslogメッセージのフォーマットが$syslogFormatterという値で変更されていることがわかります。syslogは各ログエントリに日付/時刻を挿入するので、これらの値をログテキストに含める必要はありません。syslog機能はlocal0に設定され、すべてのWARNINGメッセージはsyslogにともに送信され、INFOレベルのメッセージとWARNINGレベルのメッセージはローカルファイルに記録されます。Syslog機能とログレベルに関する追加情報は、Syslog Wikipediaのページを参照してください。

Logging to CloudWatch Logs

Monologの基本的な使い方を見てきたので、いくつかのログをCloudWatch Logsに送りましょう。Monologライブラリ用のAmazon Web Services CloudWatch Logs Handlerを使用して、MonologをCloudWatch Logsに統合することができます。この例では、認証アプリケーションによってログ情報が生成されます。

use Aws\CloudWatchLogs\CloudWatchLogsClient;
use Maxbanton\Cwh\Handler\CloudWatch;
use Monolog\Logger;
use Monolog\Formatter\LineFormatter;
use Monolog\Handler\StreamHandler;
use Monolog\Handler\SyslogHandler;

$logFile = "testapp_local.log";
$appName = "TestApp01";
$facility = "local0";

// Get instance ID:
$url = "http://169.254.169.254/latest/meta-data/instance-id";
$instanceId = file_get_contents($url);

$cwClient = new CloudWatchLogsClient($awsCredentials);
// Log group name, will be created if none
$cwGroupName = 'php-app-logs';
// Log stream name, will be created if none
$cwStreamNameInstance = $instanceId;
// Instance ID as log stream name
$cwStreamNameApp = "TestAuthenticationApp";
// Days to keep logs, 14 by default
$cwRetentionDays = 90;

$cwHandlerInstanceNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);
$cwHandlerInstanceError = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameInstance, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::ERROR);
$cwHandlerAppNotice = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ 'application' => 'php-testapp01' ],Logger::NOTICE);

$logger = new Logger('PHP Logging');

$formatter = new LineFormatter(null, null, false, true);
$syslogFormatter = new LineFormatter("%channel%: %level_name%: %message% %context% %extra%",null,false,true);
$infoHandler = new StreamHandler(__DIR__."/".$logFile, Logger::INFO);
$infoHandler->setFormatter($formatter);

$warnHandler = new SyslogHandler($appName, $facility, Logger::WARNING);
$warnHandler->setFormatter($syslogFormatter);

$cwHandlerInstanceNotice->setFormatter($formatter);
$cwHandlerInstanceError->setFormatter($formatter);
$cwHandlerAppNotice->setFormatter($formatter);

$logger->pushHandler($warnHandler);
$logger->pushHandler($infoHandler);
$logger->pushHandler($cwHandlerInstanceNotice);
$logger->pushHandler($cwHandlerInstanceError);
$logger->pushHandler($cwHandlerAppNotice);

$logger->info('Initial test of application logging.');
$logger->warn('Test of the warning system logging.');
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-success' ]);
$logger->notice('Application Auth Event: ',[ 'function'=>'login-action','result'=>'login-failure' ]);
$logger->error('Application ERROR: System Error');

この例では、アプリケーション認証イベントはPHP配列として渡され、JSONとしてCloudWatch Logsに表示されます。login-successおよびlogin-failureの結果を伴うイベントは、インスタンスIDに関連付けられたログストリームと、アプリケーション名に関連付けられたログストリームの両方に送信されます。

これらの異なるストリームの場所を使用して、インスタンスごとまたはアプリケーションごとにメトリックとアラームを作成できます。過去5分間にアプリケーションにログインしたユーザーの総数に対するメトリックを作成するとします。イベント・グループを選択し、メトリック・フィルターの作成を選択します。

次のページでは、フィルタとテストを同じウィンドウで作成できます。フィルタデータについては、ログエントリのJSON文字列を使用します。すべての正常なログインを抽出するには、次の文字列を入力します。

{ $.result = login-success }

下記のように、フィルタの詳細が表示されます。フィルタ名を識別しやすい値に変更しました。メトリック名前空間にはアプリケーション名に関連付けられた値があり、メトリック名にはログイン成功数が反映されます。

CloudWatch Logsを介して受け取ったこの情報に基づいて、アラームを作成して通知を送信したり、(Amazon EC2スケーリングの決定などの)アクションとることができます。

これらの値を使用すると、5分以内に50回以上ログインが成功するたびに警告が表示されます。

Laravel logging

Monologは、一般的なLaravel PHPフレームワークを含む多くのPHPアプリケーションとフレームワークのロギングソリューションとして使用されています。この例では、Laravel内でMonolog with CloudWatch Logsの使用を示します。最初のステップは、Laravelアプリケーションの現在のログ設定を調べることです。アプリケーションルート内でconfig/app.phpを開くと、さまざまなログ設定が表示されます。デフォルトでは、Laravelはデバッグのベースラインログレベルを使用して単一のログファイルにログするように設定されています。

次に、ここからの説明と例を使用して、Laravel内のサービスプロバイダとしてAWS SDK for PHPを追加します。

また、CloudWatchログのMonologライブラリをcomposer.jsonファイルに追加して、アプリケーションに含めることもできます（図を参照）。

これで、現在のLaravel Monolog構成をカスタム構成で拡張する必要があります。この手順の詳細は、Laravel Error and Loggingページを参照してください。以下は、bootstrap/app.phpファイルへの追加例です。

use Maxbanton\Cwh\Handler\CloudWatch;

$app->configureMonologUsing( function($monolog) {

    $cwClient = App::make('aws')->createClient('CloudWatchLogs');
    $cwGroupName = env('AWS_CWL_GROUP', 'laravel-app-logs');
    $cwStreamNameApp = env('AWS_CWL_APP', 'laravel-app-name');
    $cwTagName = env('AWS_CWL_TAG_NAME', 'application');
    $cwTagValue = env('AWS_CWL_TAG_VALUE', 'laravel-testapp01');
    $cwRetentionDays = 90;
    $cwHandlerApp = new CloudWatch($cwClient, $cwGroupName, $cwStreamNameApp, $cwRetentionDays, 10000, [ $cwTagName => $cwTagValue ] );

    $monolog->pushHandler($cwHandlerApp);
});

テスト目的のために、routes/web.phpのテストルートにロギングコールを追加します。

Route::get('/test', function () {
    Log::warning('Clicking on test link!!!');
    return view('test');
});

テストルートが呼び出されると、ログはCloudWatch Logsに表示されるようになりました。

結論

この例では、PHP Monologを使用してローカルファイル、syslogおよびCloudWatch Logsにログを書き込む方法を紹介しました。また、一般的なPHPアプリケーションフレームワーク内で、MonologとCloudWatch Logsの統合を実施しました。最後に、CloudWatch Logsメトリックフィルタを作成し、CloudWatch Alarmsに適用して、ログからのデータを通知とともにスケーラビリティの決定とともに実行可能にする方法をご紹介しました。CloudWatch Logsは、PHPアプリケーションの集中的にロギング機能を提供し、Monologと組み合わせることで、確立されたプロジェクトやカスタムエンゲージメント内で使用するライブラリの可用性を保証します。
(翻訳はSA 森が担当しました。原文はこちら)

HDFSからAmazon S3へApache HBaseを移行するためのヒント

by AWS Japan Staff | on 08 MAY 2017 | in Amazon EMR, Amazon S3 | Permalink

Amazon EMR 5.2.0以降、Amazon S3上でApache HBaseを実行することができます。 S3上でHBaseを実行すると、コストの削減、データ耐久性の向上、スケーラビリティの向上など、いくつかの利点が追加されます。

HBaseには、HBaseテーブルの移行およびバックアップに使用できるいくつかのオプションがあります。 S3のHBaseに移行する手順は、Apache Hadoop分散ファイルシステム（HDFS）のHBaseの手順と似ていますが、細かな違いといくつかの「落とし穴」を認識していれば、移行がより簡単になります。

この記事では、一般的なHBase移行オプションのいくつかを使用してS3のHBaseを開始する方法を説明します。

HBaseの移行オプション

正しい移行方法とツールを選択することは、HBaseテーブルの移行を成功させる上で重要なステップです。しかし、正しいものを選ぶことは、必ずしも簡単な作業ではありません。

次のHBaseの機能が、S3のHBaseに移行するのに役立ちます：

スナップショット
エクスポートとインポート
CopyTable

次の図は、各オプションの手順をまとめたものです。

さまざまな要因によって、使用するHBaseの移行方法が決まります。たとえば、EMRでは、S3で実行できる最初のバージョンとしてHBaseバージョン1.2.3が提供されています。したがって、移行元のHBaseバージョンが、移行方法を決決めるのに役立つ重要な要素になります。 HBaseのバージョンと互換性の詳細については、Apache HBaseリファレンスガイドのHBaseのバージョン番号と互換性のマニュアルを参照してください。

旧バージョンのHBase（HBase 0.94など）から移行する場合は、アプリケーションをテストして、新しいHBase APIバージョンと互換性があることを確認する必要があります。アプリケーションとAPIにHBaseバージョンの違いによる問題があることを確認するためだけに、大きなテーブルを移行して数時間を費やすことは望ましくありません。

良い知らせとしては、HBaseはテーブルの一部だけを移行するために使用できるユーティリティを提供していることです。これにより、HBaseテーブル全体を完全に移行することなく、既存のHBaseアプリケーションをテストすることができます。たとえば、Export、Import、またはCopyTableユーティリティを使用して、テーブルの一部分をS3のHBaseに移行できます。アプリケーションが新しいHBaseバージョンで動作することを確認したら、HBaseスナップショットを使用してテーブル全体を移行することができます。

(more…)

AWS と EU の一般データ保護規則 (GDPR)

by AWS Japan Staff | on 08 MAY 2017 | in General | Permalink

ちょうど 1 年ほど前、欧州委員会は新しい「EU一般データ保護規則」（General Data Protection Regulation, GDPR）を承認し、採択しました。ヨーロッパにおけるデータ保護についての法律において、GDPR は 1995 年に導入された「EUデータ保護指令」（「指令 95/46/EC」とも知られている) 以来の大きな変化です。GDPR は EU における個人データ（personal data）のセキュリティや保護を強化を目指しており、EUデータ保護指令や関連する全ての特定地域の法律を置き換えます。

AWS は GDPR の制定を歓迎します。この新しい強固な要件はデータの保護、セキュリティ、コンプライアンスの基準を引き上げ、最も厳しい統制に従うよう産業界を後押し、全ての方を安全になるよう助けます。GDPR が 2018年5月25日に施行される際に、全ての AWS サービスは GDPR に適合することをアナウンスさせて頂きます。

このブログ記事では、お客様が EU データ保護要件に対応する事ができるよう AWS は継続的に支援して行くというコミットメントの一部として、GDPR についてお客様を支援させて頂く内容を説明します。

AWS は何をしてくれるか？

AWS は世界中にある全てのリージョンにわたってセキュリティやコンプライアンスについて高い基準を継続して維持します。セキュリティは常に我々にとって最も優先順位の高い「０番目の仕事」(job zero) です。AWS クラウドは現在実現できる最も強力で、柔軟性が高く、安全なクラウドコンピューティング環境をお客様に提供できるように設計されています。また AWS 上でお客様が GDPR 要件を満たしたインフラストラクチャ構築が行えるように多数のサービスやツールを提供しています。

ツールの一つは、AWS データ処理契約 (Data Processing Agreement, DPA) です。GDPR の要件を満たすようになる DPA を準備できたことを本日アナウンスさせて頂きます。この GDPR DPA は施工される 2018年5月25日に向けての準備を支援するために全ての AWS のお客様に提供可能です。新しい GDPR DPA について追加の情報や文章の入手については、AWS担当にお問い合わせください。

担当に加え、ヨーロッパ全域のお客様に協力させて頂いるコンプライアンスのエキスパート、データ保護のスペシャリスト、セキュリティのエキスパートのチームがあり、質問に回答したり、GDPR 施行後に AWS クラウド内で稼働させるシステムの準備を支援しています。また、ご質問にさらに回答できるよう EU データ保護のウェブサイトを更新しました（日本語版も反映済み）。ウェブサイトには、GDPR が何であるかや、EU 内で活動を行っている組織に与える変化、お客様に GDPR を満たす手助けになる AWS のサービス、どのように準備することができるかのアドバイスを載せています。

EU データ保護のウェブサイトに掲載しているもう一つのトピックは、CISPE Code of Conduct (行動規則) についての AWS のコンプライアンスについです。CISPE Code of Conduct は、クラウドを利用されるお客様が GDPR に準拠したルールに従ってデータを保護するために、クラウド提供会社が適切なデータ保護標準を利用しているかを確認するのに役立ちます。AWS は、Amazon EC2、Amazon S3、Amazon RDS、AWS Identity and Access Management (IAM)、AWS CloudTrail、Amazon Elastic Block Storage (Amazon EBS) が CISPE Code of Conduct に十分に適合していると宣言します。この宣言は、AWS を使う際に、安全で準拠した環境でデータを統制していることを保証します。CISPE Code of Conduct についての AWS のコンプライアンスについてより詳細な内容については、CISPE のウェブサイトを確認してください。

GDPR に準拠した環境を構築するために多数のツールやサービスを提供しているのと同様に、国際的に認められている多数の認証や評価を取得しています。この過程で、AWS はクラウドセキュリティについての ISO 27017、クラウドプライバシーについての ISO 27018、PCI DSS レベル 1、SOC 1/2/3 のような第三者認証のフーレムワークに準拠している事を実証しています。また、AWS はドイツにおいて重要な BSI のクラウドコンピューティングコンプライアンスコントロールカタログ (C5) のように各地域固有のセキュリティ標準に対応できるよう支援しています。AWS は引き続きお客様にとって重要な認証や評価に追従していきます。

あなたは何ができるか？

GDPR は 2018年5月25日まで適用されませんが、AWS はお客様やパートナー様が準備を始められる事をお薦めしています。もし既にコンプライアンスやセキュリティ、データプライバシーについて高い基準を実現されていれば、GDPR に対応することは単純なはずです。しかしながら、GDPR コンプライアンスへの対応をまだ始めていなければ、2018年5月までにスムーズに対応すためにセキュティやコンプライアンス、データ保護プロセスの見直しを今すぐ開始する事を強くお薦めします。

GDPR コンプライアンスへの準備には以下のキーポイントを考慮してください。:

適用範囲 – あなたの組織の活動に GDPR が適用されるかを判断することは、コンプライアンス責任を果たすに重要なポイントです。

データ主体の権利 – GDPR はデータ主体 (Data Subjects, 個人データに関連する該当個人) の権利を様々な方法で拡大させます。個人データの処理をするのであれば、データ主体の権利を受け入れることができるか確認する必要があります。

データ侵害の通知 – データ管理者の場合、データ侵害（漏洩）に気づいた際にはどのようなイベントであっても遅れずに 72 時間以内に監督機関に報告しなければいけません。

データ保護責任者 (DPO) – データセキュリティや個人データ処理に関連するその他の事項を管理する DPO の選任が必要な場合があります。

データ保護影響評価 (DPIA) – データ処理について評価を行い、幾つかの状況では DPIA を監督機関に申告する必要がある場合があります。

データ処理契約 (DPA) – 個人データを欧州経済領域 (EEA) 域外に移転させる場合は特に、GDPR の要件を満たす DPA が必要になるかと思います。AWS はお客様が GDPR の要件を満たす事を助けるアクセスコントロール、監視、ロギング、暗号化など幅広いサービスと機能を提供しています。これらのサービスや機能についてより詳しい情報は EU データ保護を確認してください。

AWS ではセキュリティ、データ保護、コンプライアンスを最優先事項とし、お客様がヨーロッパと世界中を分断せずに AWS のセキュリティやコンプライアンスの恩恵を得られるように弛まずに働き続けていきます。また 2018年5月に向けて、GDPR の要件を満たす支援をするために今後ニュースやリソースを提供してきます。

– スティーブ（翻訳はSA 辻が担当しました。原文はこちらです。）

Amazon Chime の更新 – 既存の Active Directory を使用してドメインを要求

by AWS Japan Staff | on 05 MAY 2017 | in Amazon Chime | Permalink

Amazon Chime については 2 月のブログ「Amazon Chime – 統合されたコミュニケーションサービス (Amazon Chime – Unified Communications Service)」で紹介し、世界中にいる相手と繋がったり共同作業を行う方法についてご説明しました。Amazon Chime はリリースされるとすぐに AWS チームが好んで使用するコミュニケーションツールになりました。私は 1 日に渡り、1 対 1 のチャットやグループチャットにいくつも参加しています。また、Amazon Chime を使用した会議に「チャイムイン」することも頻繁にあり、今後のリリースや講演のチャンスなどについて話し合っています。本日、その Amazon Chime に新しい 2 つの機能を追加することになりました。ドメインを独自のものとして要求したり、既存の Active Directory のサポートが可能になります。

ドメインの要求
ドメインを要求することで、そのドメイン内のユーザー全員による Amazon Chime の使用状況を管理できます。新社員を公式な方法で Amazon Chime に登録させることで、社員が退社した場合はそのアカウントを停止にすることができます。ドメインを要求するには、特定のドメイン名を所有していることをアサートし、ご自分のドメインの DNS エントリに TXT レコードを入力することでアサーションをバックアップします。お客様の組織が使用するメールアドレスのドメインおよびサブドメインそれぞれにおいて、この手順を行ってください。では次に、私が自分のドメインを要求したケースをお見せします。

[Verify this domain] をクリックすると Amazon Chime が私の DNS レコードを提供します。

そうすると、ドメインのステータスが [Pending Verification] に変わります。Amazon Chime が、予期していたように新しいレコードが存在することを確認するとステータスが [Verified] に変わり、チームアカウントがエンタープライズアカウントになります。

Active Directory のサポート
この機能はユーザーが既存の Active Directory のアイデンティティと認証情報を使用して Amazon Chime にサインインできるようにします。設定が完了すると、パスワードローテーションやパスワードの複雑なルール、多要素認証などアドバンスド AD セキュリティ機能を有効にして活用することができます。さらに、グループベースで Amazon Chime の Plus や Pro ライセンスの割り当てを管理することもできます (各ライセンスタイプの詳細についてはプランと料金表をご覧ください)。この機能を使うには Amazon Chime エンタープライズアカウントを使用している必要があります。チームアカウントをご利用されている場合は、操作を始める前に「エンタープライズアカウントを作成するには (Create an Enterprise Account)」に記載されている手順をご覧ください。次に AWS Directory Service でディレクトリをセットアップします。この時点ではオプションが 2 つあります。

AWS Directory Service AD Connector を使用して、既存のオンプレミス Active Directory インスタンスに接続します。
スタンドアロン使用で設定されている Microsoft Active Directory を使います。このオプションの詳細については「Microsoft AD Directory を作成するには (How to Create a Microsoft AD Directory)」をご覧ください。

ディレクトリの設定が完了したら [Settings] をクリックし [Active directory] を選択してドロップダウンメニューでご自分のディレクトリを選ぶと、Amazon Chime コンソールから接続できるようになります。

完了したら、ディレクトリ内の各グループを選び、適切なサブスクリプション (Plus または Pro) をグループベースで指定できます。希望通りの設定が完了したら、ユーザーが既存のディレクトリ認証情報で Amazon Chime にログインできるようになります。これらの新機能はすでに利用可能であり、すぐに使用を開始できます。Amazon Chime の詳細については AWS テックトークをご覧ください:「Amazon Chime で従来のミーティングを近代化 (Modernize Meetings with Amazon Chime)」: トークのプレゼンテーション:

— Jeff;

SAP on AWSクラウド設計入門

by AWS Japan Staff | on 03 MAY 2017 | in SAP | Permalink

Rahul Kabraは、Amazon Web Services(AWS)のパートナーソリューションアーキテクトです。

SAPワークロードをAWS上に移行することを真剣に検討し始めると、AWS上のSAPアーキテクチャはどのようにすべきか、オンプレミスやプライベートクラウドで稼働する場合とどこが違うのか、ビジネスにどういった利点があるのか、おそらく気になってくるでしょう。この入門用のブログでは、これらのトピックの多くに触れ、AWS上へのSAPワークロードの移行および運用に向けた準備を整えるための重要な情報をお伝えします。

AWSがもたらす俊敏性と拡張性をSAPワークロードで実際に活用するために、AWS上のSAPランドスケープの設計では、考え方を少し変える必要があります。また、SAPアーキテクチャが様々なAWSサービスをどのように活用し、これまでに比べて可用性が高く、セキュリティが強化された環境が提供されているかを理解することも重要です。SAP on AWSの概要を理解するために、様々なアーキテクチャのコンポーネントを探ってみましょう。

SAP関連の主要なAWSサービス

以下が、SAPワークロードの展開を始めるために知っておいたほうがよい主要サービスの一部です：

Amazon VPC – Amazon Virtual Private Cloud(Amazon VPC)は、AWSクラウドの論理的に隔離された区画を提供し、すべてのAWSリソースを展開します。このサービスは、関連して許可されたネットワークトラフィックだけがVPCに出入りできるよう制御する仮想ネットワーキングの機能とセキュリティを提供します。SAPのためのVPC設計およびアーキテクチャパターンの詳細については、以前投稿したブログ「SAP on AWSにおけるVPCサブネットのゾーニングパターン」を参照してください。
Amazon EC2 – Amazon Elastic Compute Cloud(Amazon EC2)は、SAPアプリケーションサーバーとデータベースをインストールできる仮想ホストを提供します。AWSは、小規模で多目的のインスタンスからSAP HANAのようなインメモリーワークロードを実行できる大容量メモリーのインスタンスまで、SAPワークロードを実行するために認定された複数のインスタンスファミリーを提供しています。
Amazon EBS – Amazon Elastic Block Store(Amazon EBS)は、AWSが提供するブロックベースのストレージサービスであり、SAPアプリケーションおよびデータベースに関連するデータ、ログファイルおよびバックアップボリュームを格納するために使用します。AWSでは複数のEBSボリュームタイプを用意しており、SAPアプリケーションのSAPS、IOPS、スループット要件に合わせて活用することができます。
Amazon EFS – Amazon Elastic File System(Amazon EFS)は、多数のEC2インスタンスから接続できる共有ファイルシステムを提供します。このファイルストレージは、/usr/sap/transや/sapmnt/<SID>などの共有ファイルをマウントする必要があるSAPスケールアウト構成で特に役立ちます。
Amazon S3 – Amazon Simple Storage Service(Amazon S3)は、スケーラブルで耐久性の高いオブジェクトベースのストレージサービスで、SAPアプリケーションのバックアップとスナップショットの保存に使用できます。
Amazon Glacier – このサービスは、スケーラビリティが高く、耐久性に優れ、コスト効率の高いオブジェクトストレージで、コンプライアンスや規制上の理由から長期的なバックアップ、アーカイブ、データ保管に使用できます。
IAM – AWS Identity and Access Management(IAM)は、AWSユーザーとグループの作成および管理に使用します。また、IAMロールによりAWSリソースへのアクセスを安全に制御することができます。
CloudWatch – Amazon CloudWatchは、AWSリソースの監視サービスです。SAPワークロードのリソース利用状況を収集するとともに、AWSリソースの変更に自動的に対応するためのアラームを作成するのに重要です。
CloudTrail – AWS CloudTrailは、AWSアカウント内で行われたすべてのAPI呼び出しを記録します。APIコールに関する重要なメトリックを取得し、SAPリソースの証跡作成を自動化できる非常に有益なサービスです。
AWS CLI – AWSコマンドラインインターフェイス(CLI)は、コマンドラインまたはスクリプトを使用して様々なAWSサービスを管理、操作するために使用できるツールです。このブログ後半の”AWS自動化”の項でいくつかのAWS CLIコマンドの例を確認できます。
Route 53 – Amazon Route 53は、スケーラビリティと可用性の高いAWS上のDNSサービスです。ホステッドゾーン、トラフィックポリシーやドメインを作成したり、AWS以外のリソースにも接続することができます。

AWSサイジングと性能

AWSプラットフォームであれば、セルフサービス方式で正しいタイプとサイズのコンピューティングリソースを展開でき、ハードウェアに大きな初期投資をする必要はありません。AWSに移行することの主な利点の1つに、ビジネスニーズの変化に合わせてリソースを調整できる拡張性と柔軟性が手に入ることが挙げられます。例えば、AWSは、SAPランドスケープをお客様の近くで安全かつ高可用な方法で運用できるよう、16のリージョンと42のアベイラビリティゾーンからなるグローバルフットプリントを提供しています。従来のオンプレミスの構成と異なり、AWSクラウドにおいては、以下に示すようにコンソールでの数クリックの操作や、簡単なAPI呼び出しで、SAP用EC2インスタンスのサイズを変更できます。

AWSマネジメントコンソールから既存のEC2インスタンスのサイズ変更

お客様が必要とする大量のリソースをすぐに利用でき、また使った分のお支払いで済みます。これにより、インフラストラクチャの設計者は、新しいプロジェクトのコンピューティング/メモリーのサイジング要件を決定する際に、バッファを加味したり推測したりすることが不要になります。また、月末や決められた期間のような特別なイベントの間だけ、既存のホストへの容量の追加やSAPアプリケーションまたはデータベース層を拡張することが容易にできます。AWSでは、リソース要件を満たすためにメモリー最適化、コンピュート最適化のインスタンスタイプを提供しており、SAP社と密に連携してどちらもSAP認定を取得しています。SAP認定EC2インスタンスのリストは、SAPノート1656099を参照してください(SAPノートの閲覧にはSAP Support Portalのユーザーが必要です)。

AWS上でSAPアプリケーションを設計するということは、すべてのSAPアプリケーションを常に稼働させる必要はないということです。サンドボックス、トレーニング、デモシステムなど、重要ではないSAPシステムのほとんどは、使用していないときには停止することができ、コストを削減できる可能性があります。

AWS上で性能を実現するための1つに、ストレージの設定方法があります。EBSボリュームはアベイラビリティゾーン内で複製されるため、データ損失から保護されています。このような理由から、EBSボリュームで最大限の性能を出すためには、RAID 0によるストライピングでよいです。これは大半のオンプレミス環境では不可能です。様々なEBSボリュームタイプと性能特性の詳細については、ブログ「SAP HANA on AWSの展開 – どのような選択肢が？」も参照してください。これらのEBSボリュームは、HANA以外のデータベースにももちろん使用できます。

AWS自動化

AWSはクラウドオートメーションのリーダーであり、基盤となるリソースをプログラム的にスクリプト化して、予測可能かつ繰返し可能な方法で操作、拡張するための複数の選択肢を提供しています。スクリプトの実行により、SAPアプリケーションサーバーの新規作成、バックアップやスナップショットの取得、最初から新しいインスタンスを構築するなど、SAPの操作を自動化できます。

稼働中のSAP HANAデータボリュームのスナップショットをバックアップ用に取得し、それらのボリュームを復元することがいかに簡単かを示す例をいくつか紹介します。これらのコマンドは容易に作成することができ、crontabやその他の時間駆動のジョブスケジューラツールからバックアップ/リカバリーの操作スクリプトの一部として簡単に実行できます。

例1: 稼働中のHANAデータボリュームのスナップショット取得

SAP HANAインスタンスの停止：
sudo su – <sid>adm -c "HDB stop"
ファイルシステムの静止：
umount /hana/data

インスタンスにアタッチされているSAP HANAボリュームのIDを識別：

aws ec2 describe-volumes --region=us-west-2 --filters Name=attachment.instance-id,Values=i-03add123456789012 Name=tag-value,Values="HANA*" --query 'Volumes[*].{ID:VolumeId,Tag:Tags}'

Response:

[
    {
        "Tag": [
            {
                "Value": "HANA_root",
                "Key": "Name"
            }
        ],
        "ID": "vol-071111111111111"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #1",
                "Key": "Name"
            }
        ],
        "ID": "vol-082222222222222"
    },
    {
        "Tag": [
            {
                "Value": "HANA_data #2",
                "Key": "Name"
            }
        ],
		"ID": "vol-0733333333333"
     }
]

SAP HANAボリュームのスナップショットを取得：
aws ec2 create-snapshot --region=us-west-2 --volume-id vol-07222222222222 --description "HANA Server Data volume #1"; aws ec2 create-snapshot --region=us-west-2 --volume-id vol-08333333333333 --description "HANA Server Data volume #2
SAP HANAデータボリュームのマウント(この操作はスナップショットがPending状態になれば可能)：
mount /hana/data
SAP HANAを起動：
sudo su - <sid>adm -c "HDB Start"

例2: スナップショットからデータを復元し、既存のホストにアタッチ

スナップショットから新しいボリュームを作成：
aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
EC2インスタンスに新しく作成したボリュームをアタッチ：
aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
読込処理を最適化するためにボリュームの初期化(本番環境では強く推奨)：
fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
SAP HANAデータに関連付けられた論理ボリュームをマウント：
mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
SAP HANAを起動：
sudo su - <sid>adm -c "HDB Start"

SAP on AWSで自動化を活用する方法は他にもあります：

Amazon Machine Images(AMI)を使用してSAPインスタンスの新しいコピーを作成できます。
AWS CloudFormationを使用して新しいSAPインスタンスの作成を自動化、AWS Quick Startを活用してクラウド内に新しいSAP HANA環境の展開を実現できます。

複数のアベイラビリティゾーンおよびまたはリージョンを使った可用性と災害対策

従来のオンプレミス構成のSAPシステムでは、同じ物理データセンター内で高可用性(HA)を取る必要がありました。対照的に、AWSは同じリージョン内の複数のアベイラビリティゾーンにまたがったHAを構成できます。アベイラビリティゾーンは、物理的に隔離されたデータセンターの集合体で、ネットワークのレイテンシーが低く、同じ地理的リージョンに接続されています。いくつかのお客様にとっては、この構成で災害復旧(DR)シナリオとしても十分ですが、そうでない場合、TCOの度合いによって国や都市の異なる2つ目のリージョンの利用といった複数の選択肢を用意しています。以下のSAP分散アーキテクチャの例をご覧ください。

AWS上のSAP分散アーキテクチャ

SAP運用

オンプレミス環境と比較して、AWSではAmazon CloudWatchやAWS CloudTrailなどの監視サービスを使うことができ、SAPシステムの運用においてこれまで以上の透明性と説明責任が得られます。AWSリソースへのきめ細かいセキュリティとアクセス制御には、IAMロールとポリシー、セキュリティグループ、そしてネットワークACLを使うことができます。

監視サービス – CloudWatchやCloudTrailのようなサービスは、リソース使用率を監視するのにも役立ちます。CloudWatchを使用すると、ハードウェア障害が発生した場合に、インスタンスを監視して自動的に復旧するアラームを作成できます。詳細はAWSドキュメントをご覧ください。
セキュリティ – IAMはAWSリソースへの洗練されたアクセス制御を可能にするだけでなく、AWSアクセスキーをコピーすることなく、異なるサービス間の安全な通信を可能とするロールも作成できます。詳細はAWSドキュメントをご覧ください。
バックアップ – Amazon S3連携をサポートするバックアップツールのいずれかを使用する場合、S3バケットに直接データベースをバックアップできます。そうでない場合は、AWS上で既存のバックアップツールを使用して、EBSボリュームにファイルをエクスポートしてからAmazon S3と同期することもできます。

AWS簡易見積りツール

AWSでは、ハードウェアと運用コストを包括的に把握することが難しいオンプレミスの世界とは異なり、オンデマンドやリザーブドインスタンスを含むEC2インスタンスの様々な支払い方法とインフラストラクチャのコストをマッピングするツールを提供しています。

次のステップ

SAP on AWSの詳細については、以下のリソースをご覧ください：

SAP on AWSホワイトペーパーを読む – SAP on AWSのアーキテクチャと展開オプションについて詳しく知るための素晴らしい資料です。
SAP on AWSブログを読む – SAP関連の様々なトピックに踏み込んだいくつかのブログがあります。
AWSトレーニングクラスに登録する – AWSでは、様々なAWSサービスを素早く習得するための優れたトレーニングリソースを提供しています。AWSテクニカルエッセンシャルのようなクラスは、これからAWSを開始する方には非常に役立ちます。
AWS認定資格を取得する – AWSソリューションアーキテクトのアソシエイトまたはプロフェッショナル認定の取得は、AWS上にSAPおよびSAP以外のアプリケーションを導入するためのアーキテクチャやベストプラクティスの手引きとして非常に役立ちます。
コンサルティングパートナーに連絡する – 日頃から深くお付き合いのあるコンサルティングパートナーがいる場合は、AWS上へのSAP移行についても相談してみてください。

– Rahul

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

EC2 の料金の値下げ – リザーブドインスタンス & M4 インスタンス

by AWS Japan Staff | on 03 MAY 2017 | in Amazon EC2, 値下げ | Permalink

AWS の拡大が進むに連れて、お客様へ提供するサービス価値も高めて行けるように努めています。サプライヤと協力してコスト低減を実現しながら、今まで以上に効率的でコスト効率が良い方法でハードウェアやソフトウェアを構築できるようにしています。定期的そして頻繁にコスト低減を行っているほか、お客様が AWS を利用する上で最適化できるオプションもご提供しています。たとえばリザーブドインスタンス (2009 年にリリース) は、オンデマンド料金に比べ Amazon EC2 ユーザーに大幅な割引を提供します。また、特定のアベイラビリティーゾーンで使用するキャパシティー予約においても同様です。AWS をご利用のお客様は様々な方法でリザーブドインスタンスを購入し管理されています。前払いでより大幅な値下げを利用するお客様もいれば、最初に何も払わずに小さな (とはいっても、かなりの額にはなりますが) 割引をご利用されるお客様もいらっしゃいます。また、その中間を取って一部前払いして先述の 2 つのオプションの間に位置する割引料金をご利用され、満足されている方もいます。このようにお客様の幅広い好みにお応えすべく、AWS では大半の現行世代のインスタンスタイプを対象に 3 年契約の前払いなしスタンダードリザーブドインスタンスをオプションを追加しました。さらに、前払いなしリザーブドインスタンス、コンバーティブルリザーブドインスタンス、汎用 M4 インスタンス (オンデマンドおよびリザーブドインスタンス) の料金の値下げも行うことになりました。これで 61^回目の AWS 料金の値下げとなります。詳細はこちらをご覧ください (すべての変更および値下げは即座に有効になります)。3 年契約のスタンダード RI で前払いなしのオプションを追加 – これまでは 1 年契約のスタンダード RI で前払いなしのオプションをご提供していました。そして本日より、3 年契約の C4、M4、R4、I3、P2、X1、T2 スタンダードリザーブドインスタンスで前払いなしのオプションも開始しました。前払いなしリザーブドインスタンスの料金を低く設定 – C4、M4、R4、I3、P2、X1、T2 インスタンスタイプで、前払いなし 1 年契約のスタンダードと 3 年契約のコンバーティブルリザーブドインスタンスを対象に、最大 17% までの料金値下げを行いました。新しい料金はインスタンスタイプやオペレーティングシステム、リージョンにより異なります。いくつかのリージョンにおける Linux の前払いなしリザーブドインスタンスの平均値下げは次の通りです。

	米国東部 (バージニア北部)	米国西部 (オレゴン)	欧州 (アイルランド)	アジアパシフィック (東京)	アジアパシフィック（シンガポール）
C4	-11%	-11%	-10%	-10%	-9%
M4	-16%	-16%	-16%	-16%	-17%
R4	-10%	-10%	-10%	-10%	-10%

コンバーティブルリザーブドインスタンスをより安価に – コンバーティブルリザーブドインスタンスはインスタンスファミリーや RI と関連のある他のパラメーターをいつでも変更できるようにします。これにより、アプリケーションの展開や変更の必要が発生した場合に RI インベントリを調整することができます。3 年契約のコンバーティブルリザーブドインスタンスの料金を大方の現行世代のインスタンス (C4、M4、R4、I3、P2、X1、T2) で、最大 21% まで値下げしました。いくつかのリージョンにおける Linux のコンバーティブルリザーブドインスタンスの平均値下げは次の通りです。

	米国東部 (バージニア北部)	米国西部 (オレゴン)	欧州 (アイルランド)	アジアパシフィック (東京)	アジアパシフィック（シンガポール）
C4	-13%	-13%	-5%	-5%	-11%
M4	-19%	-19%	-17%	-15%	-21%
R4	-15%	-15%	-15%	-15%	-15%

このような値下げは、その他ほぼすべてのリージョンでも有効になる予定です。M4 インスタンスをより安価に – M4 Linux インスタンスの料金を最大 7% まで引き下げました。新価格については EC2 リザーブドインスタンスの料金表ページと EC2 料金表ページまたは AWS 料金表 API をご覧ください。詳細次のブログは EC2 リザーブドインスタンスモデルに追加した改良点の詳細情報について説明しています。

「EC2 リザーブドインスタンスの新たなインスタンスサイズの柔軟性 (New – Instance Size Flexibility for EC2 Reserved Instances)」 – このブログはインスタンスファミリーやリージョン内で複数のインスタンスサイズに単一の RI を使用する方法について説明しています。
「EC2 リザーブドインスタンスの更新 – コンバーティブル RI のリージョン別メリット (EC2 Reserved Instance Update – Convertible RIs and Regional Benefit)」 – このブログはリージョン別メリットと (リージョン内でどの AZ でもインスタンスを実行できるように、キャパシティーの予約を適用しない) インスタンスファミリーや他のパラメーターの変更を許可するコンバーティブル RI について説明しています。
「EC2 リザーブドインスタンスモデルを単純化 (Simplifying the EC2 Reserved Instance Model)」 – このブログは 3 つの支払いオプションを紹介しています (全前払い、一部前払い、前払いなし)。

詳細は AWS 料金表やリザーブドインスタンスのよくある質問をご覧ください。

— Jeff;

【AWS Database Blog】AWS Database Migration Service におけるイベント通知

by AWS Japan Staff | on 02 MAY 2017 | in AWS Database Migration Service | Permalink

こんにちは。ソリューションアーキテクトの江川です。本日は、AWS のプロダクトマネージャーである Eran Schitzer が、AWS Database Blogに投稿したEvents and Notifications in AWS Database Migration Service を翻訳してご紹介します。

先日、AWS Database Migration Service (AWS DMS) に新機能が追加され、Amazon Simple Notification Service (Amazon SNS)を介して、Email やテキストメッセージ、HTTP エンドポイントへの通知といった形で、DMS のイベント通知を受け取れるようになりました。

お客様は2種類のイベント(DMS インスタンスに関連するイベントと、レプリケーションタスクに関連するイベント)をサブスクライブし、通知を受信できます。DMS インスタンスに関連するイベントには、可用性、設定変更、作成、削除、メンテナンスに関するイベントが含まれます。例えば、DMS インスタンスがメンテナンスにより停止すると、通知がトリガーされます。

レプリケーションタスクに関連するイベントには、タスクの開始、停止、終了、Full Load の完了、CDC の開始などのイベントが含まれます。例えば、移行タスクとしてすべてのデータを移行し終えると、“Full Load completed” という通知がトリガーされます。もし、タスクが Full Load に続けて、CDC を実行する(つまり、Full Load が開始してからのデータの変更をレプリケーションする)設定となっていた場合は、続けて “CDC started” という通知がトリガーされます。

さらに、AWS DMS ではイベントが様々なカテゴリに分類されており、ユーザーは AWS DMS コンソール、AWS DMS API を使って、そのカテゴリをサブスクライブできます。サブスクライブすることにより、そのカテゴリに関するイベントが起きた際に、通知されます。例えば、特定のレプリケーションインスタンスについての “creation(作成)”カテゴリをサブスクライブした場合、レプリケーションインスタンスが作成されているなどのような、レプリケーションインスタンスに影響を与える creation に関連したイベントが起きた際はいつでも通知がなされます。

下記の一覧は、現時点で DMS レプリケーションインスタンスについてサブスクライブできるカテゴリを示しています。

Configuration change(設定変更)—レプリケーションインスタンスの設定が変更されています
Creation(作成)—レプリケーションインスタンスが作成されています
Deletion(削除)—レプリケーションインスタンスが削除されています
Maintenance(メンテナンス)—レプリケーションインスタンスのオフラインメンテナンスが実行中です
Low storage—レプリケーションインスタンスの空きストレージが少なくなっています
Failover(フェイルオーバー)—Multi-AZ インスタンスのフェイルオーバーに関連するイベント。フェイルオーバーの有効化、開始、完了など。
Failure(失敗)—レプリケーションインスタンスで、ストレージ障害やネットワーク障害が発生しました

下記の一覧は、現時点で DMS レプリケーションタスクについてサブスクライブできるカテゴリを示しています。

State change— レプリケーションタスクが開始もしくは停止されました
Creation(作成)—レプリケーションタスクが作成されました
Deletion(削除)—レプリケーションタスクが削除されました
Failure(失敗)—レプリケーションタスクが失敗しました

AWS DMS によるイベントとイベントカテゴリの一覧は、ドキュメントのイベントと通知の使用を参照してください。

AWS DMS イベントをサブスクライブするには、以下の通り行います。

Amazon SNS トピックを作成します。このトピックには、どんなタイプの通知を受け取りたいか、受け取るアドレスや電話番号を設定します。
AWS マネジメントコンソール、AWS CLI, もしくは AWS DMS API を通じて、AWS DMS イベント通知のサブスクライブを行います。
AWS DMS のイベント通知を受け取るための承認メールもしくは SMS メッセージを受け取り、E メール、SMS メッセージ内のリンクをクリックして、サブスクライブの確認を行います。

サブスクライブしたことを確認すると、AWS DMS コンソールの Event Subscriptions セクションにて、お客様のサブスクリプションのステータスが更新されます。

そして、イベント通知の受信が開始されます。

コンソールを使ったテーブルマッピングについての詳細は、DMS ドキュメントを参照ください。

AWS Database Migration Service 全般に関する詳細は、こちらのウェブサイトを参照ください。

← Older posts