Amazon Web Services ブログ

ランサムウェア「WannaCry」に関するAWSへの影響について

by AWS Japan Staff | on | in Amazon EC2, Amazon EC2 Systems Manager, Amazon Inspector, Amazon WorkSpaces, AWS Directory Service, AWS Elastic Beanstalk, セキュリティ |

(2017/05/19 10:00 追記)

(2017/05/18 17:35 追記)

2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。

このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server(4013389)の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。

 

WannaCryによるAWSサービスへの影響

 

EC2 Windows

 

Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。

AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。

AWSのWindows AMIのリリースノートはこちらです。

 

WorkSpaces

 

Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。

 

Directory Service

 

AWS Directory Serviceに関しては、現在パッチ適用作業中ですが、お客様のVPCからのみアクセスを許可するデフォルトの構成であれば、既に外部の攻撃からは保護されています。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。

 

Elastic Beanstalk

 

AWS Elastic Beanstalkに関しては、2017 年5月4日以降のWindowsサーバーで構築された環境は、本問題の影響を受けません。ただし、既存のElastic Beanstalk Windows環境のアップデートは常に推奨しています。AWS管理コンソールから、もしくは、環境を再構築することでアップデート可能です。Elastic Beanstalkの現時点での最新のリリースノートはこちらです。

 

AWSによるセキュリティ速報(原文)は、こちらをご覧ください。

 

AWSサービスの効果的な使い方

 

Amazon Inspectorは、Amazon EC2インスタンスに対してエージェントを導入し、セキュリティ診断を行うサービスです。CVE(共通脆弱性識別子)のルールパッケージに基づいた診断も可能で、WannaCryに関連するCVE-2017-0143からCVE-2017-0148の脆弱性の検証ができます。AWS管理コンソール、CLI、APIから診断を実行できます。診断結果は、AWS管理コンソールで表示したり、エグゼクティブサマリー含むPDF形式のレポートとしても取得できます。

AWSコンソール上でのAmazon Inspector 結果一覧画面例

 

AWSコンソール上でのAmazon Inspector 結果詳細画面例

 

詳しくは、Amazon Inspector ユーザーガイドをご覧ください。

 

Amazon EC2 Systems Managerは、Amazon EC2インスタンスおよびオンプレミスサーバーに対してエージェントを導入し、ソフトウェアインベントリ収集やOSパッチ適用、OS構成変更などを一元的に管理できるサービスです。インスタンスに対して、シェルスクリプトやPowerShellコマンドの実行、パッチ適用の時間指定や定期実行などの管理タスクを簡単に自動化できます。今回のような、Windowsのセキュリティ更新プログラム適用にもご利用いただけます。詳しくは、Amazon EC2 Systems Manager ユーザーガイドをご覧ください。

 

推奨するAWSソリューション

 

今回のようなランサムウェアに対する最も有効な対策は、常日頃からバックアップを取得・管理し、セキュリティ推奨構成を保っておくことです。AWSではバックアップ&復旧に関する各種ソリューションの情報が提供されています。

上記の情報も参考に、これからも安心・安全なAWSライフをご満喫ください。

桐山 隼人, セキュリティソリューションアーキテクト
坪 和樹, クラウドサポートエンジニア
長谷川 淳, クラウドサポートエンジニア

EC2インメモリ処理のアップデート: 4TBから16TBのメモリ搭載インスタンスと34TBのSAP HANAスケールアウト

by AWS Japan Staff | on | in Amazon EC2, SAP |

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。

その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。

ここで、この分野での最も重要なお知らせを簡単にまとめておきます:

2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました

2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました

2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました

2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました

2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました

2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました

2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました

2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました

現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています(SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています)。

私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました(閲覧には登録が必要)。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです:

SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します:

  • より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード(34TBメモリ)まで構成できるようになりました
  • 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します
  • 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています

詳細をみてみましょう!

より大きなSAP HANAクラスタ
SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード(34TBメモリ)のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます(詳細は、SAP HANA認定ハードウェアディレクトリx1.32xlargeインスタンスを参照してください)。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。

メモリ重視のX1ファミリの拡張
お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。

今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、(x1.32xlargeの2倍の)4TBのDDR4メモリ、128個のvCPU(4つの2.3 GHz Intel ® Xeon® E7 8880 V3プロセッサ)、高いメモリ帯域幅および大きなL3キャッシュを提供します。このインスタンスはVPC専用で、レイテンシとジッターを最小限に抑えながら、Elastic Network Adapterを使用して最大20Gbpsのネットワーク帯域幅を提供します。また、デフォルトでEBS最適化が行われており、最大14GbpsのEBSへの専用スループットが設定されます。

いくつかのシェルのスクリーンショットです。最初に、dmesgでブート時のカーネルメッセージを表示します:

次に、lscpuでvCPUとソケット数を他の多くの興味深い項目と共に表示します:

そして、topでは約900のプロセスを表示しています:

SAP HANA Studioの画面です:

以下の図からわかるように、この新しいインスタンスにより、大規模クラスタの認定と合わせて、EC2上でSAPを実行するためのスケールアウトオプションとスケールアップオプションの組合せを広げます。

長期的なメモリ重視のロードマップ
大規模なSAP導入の計画にはかなりの時間がかかることも分かっているので、ロードマップの一部を共有したいと考えています。

現在、サードパーティのコロケーション施設でより大規模なSAP HANA認定サーバを稼働させ、AWS Direct Connectを使用してAWSインフラストラクチャに接続することができますが、お客様は既に利用されているX1インスタンスのようなクラウドネイティブソリューションを必要としていると仰っています。

このご要望を満たすために、私たちはより多くのメモリを持つインスタンスを計画しています!2017年から2018年にかけて、8TBから16TBのメモリのEC2インスタンスを提供する予定です。これらの今後のインスタンスは、x1e.32xlargeと共に、より大きなシングルノードのSAP導入およびマルチノードのSAP HANAクラスタの作成、さらに他のメモリ重視のアプリケーションやサービスの実行を可能にします。また、小規模なインスタンスで限界に達するときに役立ついくつかのスケールアップへの余力も提供します。

できるだけ早く私たちの計画に関する詳細情報を共有していきます。

SAPPHIREで会いましょう
AWSは、SAPPHIREの539番ブースに出展しており、ブース内のシアターで私たちのチームやお客様、パートナーからの一連のセッションを予定しています。また、イベントを通じて多くのセッションに関与しています。例えば以下のようなものです(詳細は、SAP SAPIRE NOW 2017を参照してください)。

SAP Solutions on AWS for Big Businesses and Big Workloads – 5月17日水曜正午から、Bas Kamphuis (General Manager, SAP, AWS)とEd Alford氏 (VP of Business Application Services, BP)が講演

Break Through the Speed Barrier When You Move to SAP HANA on AWS – 5月17日水曜午後12時30分から、Paul Young氏 (VP, SAP)とSaul Dave氏 (Senior Director, Enterprise Systems, Zappos)が講演

AWS Fireside Chat with Zappos (Rapid SAP HANA Migration: Real Results) – 5月18日木曜午前11時から、Saul Dave氏 (Senior Director, Enterprise Systems, Zappos)とSteve Jones (Senior Manager, SAP Solutions Architecture, AWS)が講演

Jeff;

追伸 – もし、SAPの経験をお持ちで、そのキャリアをクラウドで活かしたい場合は、プリンシパルプロダクトマネージャー(AWSクイックスタート)SAPアーキテクトのポジションにご応募ください。

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

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

by AWS Japan Staff | on | in Amazon Kinesis |

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

Amazon Kinesis StreamsAmazon 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 | in Amazon EC2, Apache MXNet, Deep Learning |

今年の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 IoTAWS Greengrassといったサービスを通じてこれらのデバイスを管理することができるので、end-to-endのAIワークフローを提供することができます。

さらに学ぶには

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

AWS Batch上で深層学習

by AWS Japan Staff | on | in Amazon ECS, AWS Batch, Deep Learning |

同僚の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 | in Amazon CloudWatch, Log, PHP |

ロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。今回の例では、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 | in Amazon EMR, Amazon S3 |

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 | in General |

ちょうど 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 は世界中にある全てのリージョンにわたってセキュリティやコンプライアンスについて高い基準を継続して維持します。セキュリティは常に我々にとって最も優先順位の高い「0番目の仕事」(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 | in Amazon Chime |

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 つあります。

  1. AWS Directory Service AD Connector を使用して、既存のオンプレミス Active Directory インスタンスに接続します。
  2. スタンドアロン使用で設定されている 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 | in SAP |

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データボリュームのスナップショット取得

  1. SAP HANAインスタンスの停止:
    sudo su – <sid>adm -c "HDB stop"
  2. ファイルシステムの静止:
    umount /hana/data
  3. インスタンスにアタッチされている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"
         }
    ]
    
  4. 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
  5. SAP HANAデータボリュームのマウント(この操作はスナップショットがPending状態になれば可能):
    mount /hana/data
  6. SAP HANAを起動:
    sudo su - <sid>adm -c "HDB Start"

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

  1. スナップショットから新しいボリュームを作成:
    aws ec2 create-volume --region us-west-2 --availability-zone us-west-2a --snapshot-id snap-1234abc123a12345a --volume-type gp2
  2. EC2インスタンスに新しく作成したボリュームをアタッチ:
    aws ec2 attach-volume --region=us-west-2 --volume-id vol-4567c123e45678dd9 --instance-id i-03add123456789012 --device /dev/sdf
  3. 読込処理を最適化するためにボリュームの初期化(本番環境では強く推奨):
    fio --filename=/dev/xdf --rw=randread --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
  4. SAP HANAデータに関連付けられた論理ボリュームをマウント:
    mount /dev/mapper/hanaexpress-lvhanaexpressdata /hana/data
  5. 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の詳細については、以下のリソースをご覧ください:

– Rahul

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