Author: AWS Japan Staff


Amazon Lightsail、東京リージョンにて提供開始

こんにちは、ソリューションアーキテクトの塚田です。
お待たせしました。現在開催中のAWS Summit Tokyo 2017 キーノートにてアマゾンウェブサービスジャパン株式会社社長の長崎からアナウンスがあったとおり、Amazon Lightsail が東京リージョンにやってきました!


インスタンスの作成時に、リージョンとアベイラビリティゾーンで東京(ap-northeast-1)を選択することができます。


Tokyo, Zone A (ap-northeast-1a)を選んでインスタンスの作成をすすめると…

東京リージョンにLightsailのサーバが立ちました!

また、東京リージョンでも料金は変わらず、月額$5〜のプランが利用可能になっています。

色々とはかどりますね。

 

(more…)

AWS上へのSAP移行 FAST with the SAP Rapid Migration Test Program

Somckit Khemmanivanhは、Amazon Web Services(AWS)のSAPソリューションアーキテクトです。

お客様がオンプレミス環境でSAP HANA以外のデータベース(AnyDB)で稼働するSAPアプリケーションを利用されている場合、AWSが提供するSAP Rapid Migration Test Programにより、今すぐAWS上のSAP HANA(あるいはSAP ASE)ベースのアプリケーションに移行していただけます。SAP Rapid Migration Test Program(Fast AWS and SAP Transformationを略したFASTとも呼んでいます)では、SAPアプリケーション(SAP ECCやSAP Buisness Warehouse)をAnyDBで稼働中のお客様のSAP HANA on AWS移行、またはSAP ASE on AWS移行を支援するため、SAPとAWSが協力して開発した一連のプロセス、手順、ツールを提供します。

お客様自身の社内リソース、リモートコンサルティング、またはコンサルティングパートナーを活用し、FASTを適用することで、SAPシステムをAWS上に移行し、同時にSAP HANAにアップグレードすることができます。AWSは、AWSプラットフォームの柔軟性とスケールが評価され、このイニシアチブの開発およびローンチパートナーとしてSAP社に選ばれました。SAPとAWSはプログラムのパイロット段階から連携し、わずか48時間で、またインフラストラクチャコストはわずか1,000ドルで移行が完了できることを確認しています。

FASTの一環として、SAPアプリケーションの移行テストを加速させるために、SAP社はSoftware Update Manager(SUM)のDatabase Migration Option(DMO)を機能拡張しています(SAP Note 2377305を参照、SAPノートの閲覧にはログイン認証が必要です)。このSUM 1.0 SP 20の機能拡張は、DMO with System Moveと呼ばれ、特別なエクスポートおよびインポートプロセスにより、オンプレミス環境からAWS上に直接移行することができるようになっています。AWS Quick Start for SAP HANAでAWS上にSAP HANAインスタンスを迅速に展開し、SAPアプリケーションを素早く構築することができます。さらに、SAPフラットファイルをAWS上に転送するときに、Amazon S3Amazon EFS (AWS Direct Connect経由)、AWS Storage GatewayのファイルインターフェースAWS SnowballといったAWSサービスもご利用いただけます。

SUM DMOツールは、AnyDBからSAP HANAへのデータ変換時に、OS更新、リリースアップグレード/エンハンスメントパッケージの適用およびユニコード変換まで同時に実行できます。実行記録はフラットファイルに書き込まれ、AWSプラットフォーム上で迅速に展開されたSAP HANA環境に転送されます。DMO with System Moveの次の段階で、フラットファイルがインポートされ、抽出されたデータ、コード、および設定を使用して移行先のSAPアプリケーションを構築します。関連する主要なステップの概念的な流れは次のとおりです。

ステップ1では、SUM DMOツールを使用して、SAPソースデータをフラットファイルの形式でストレージ格納先にエクスポートします。利用用途や要件に応じて、この格納先は、既に設定済みの既存のAWSサービス(Amazon EFSやファイルゲートウェイなど)、またはソースサーバ上のローカルファイルシステムになります。ステップ2では、エクスポートされたフラットファイルをAWS上に転送します(注:ストレージ格納先の機能によっては、ファイルをAWS上に明示的に転送する必要はありません。例えば、Amazon EFSまたはAWS Storage Gatewayのファイルゲートウェイを使用した場合、ファイルは自動的にAWSに転送されます)。ファイルを転送している間に、AWS Quick Start for SAP HANAを使用してSAP HANA環境を展開し、オプションでSAP HANAもインストールします。SAP HANAの標準的な展開時間は、SAP HANAの大規模スケールアウトシステムの場合でも、30分から1時間未満です。最後に、ステップ3で、新しく展開されたSAP HANA環境に実際にフラットファイルをインポートする作業が行われます。

SAP Rapid Migration Test Programでは、SAP HANAライセンスを持っていないお客様は、SAPアカウントチームから限られたテストライセンスを取得することができます。お客様は、自身でDMO with System Moveを使用することも、AWS Partner Network(APN)のSAPパートナーに支援依頼することもできます。

私たちは、AWS上でのSAPアプリケーションの利用経験についてお聞きしたいと思っています。ご不明な点がありましたら、ぜひお気軽にお問合せください。

閲覧ありがとうございました!

– Somckit

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

政府統一基準に対応したAWSクラウド利用のセキュリティリファレンス提供の取り組み@パブリックセクターシンポジウム ~AWS Summit Tokyo 2017~

 

政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスについて

 

アクセンチュア株式会社、株式会社NTTデータ、PwCあらた有限責任監査法人、富士ソフト株式会社は共同で、内閣サイバーセキュリティセンター(NISC)制定の政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスを作成し、2017年3月23日より無償提供を開始しました。本リファレンスは、2016年8月31日に改訂された「政府機関の情報セキュリティ対策のための統一基準(平成28年度版)」を背景としており、クラウドの選定および利用の際のガイドラインやセキュリティ要件等の基準が追加されたことに対して、AWSクラウド環境におけるセキュリティ対応策の詳細を網羅的に提示しています。

サイバーセキュリティ基本法に基づいてNISCが制定する政府統一基準(以下、NISC統一基準)は、国内の政府機関が実施すべきセキュリティ対策の指針として幅広く利用されています。一方で、その要件やチェック項目は複雑かつ広範にわたるため、AWSクラウド等のクラウドを利用する際に、そのガイドラインや要件を満たすことを確認することは容易ではありませんでした。このたび共同開発した本リファレンスは、各社の情報セキュリティ対策に関する知見と実績を結集したものです。政府統一基準への準拠のノウハウを具体的に提示することにより、各政府機関が安全で信頼性の高いシステムを実現することを支援できるものと期待しています。

 

パートナー各社の取り組み

 

2017年5月30日に開催された「パブリックセクタ― シンポジウム ~AWS Summit Tokyo 2017 – Dive Deep Day~」にて、本リファレンスの作成者であるパートナー各社によるパネルディスカッションが行われ、各社の取り組みが紹介されました。

(more…)

6 月の AWS Black Belt オンラインセミナーのご案内

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー 6 月の配信についてご案内させて頂きます。6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催予定のAWSサミットの振り返り、Lambda書籍発売を記念したLambdaの網羅的なサービス解説など幅広いラインナップでお送ります。

6 月の開催予定

サービスカット

6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説
6/14(水) 18:00-19:00 検討中
6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service
6/28(水) 18:00-19:00 AWS Code Services Part 2

ソリューションカット

6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ
6/20(火) 12:00-13:00 Lambda書籍発売記念

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

Amazon EC2 Container Service – リリースに関する要約、お客様事例、コードについて

今回は、去年 Amazon EC2 Container Service に追加したいくつかの機能に関する概要と、お客様事例やコードについてご紹介します。このサービスは EC2 インスタンスのマネージド型クラスターの範囲内で Docker コンテナをいくつでも実行しやすくします。また、同サービスはコンソールAPICloudFormationCLIPowerShell のサポートも備えています。簡単にアクセスできるように、Linux や Windows Docker イメージを EC2 Container Registry に保存できます。

リリースの要約
それでは ECS の最新機能と、その使用方法を説明したブログをいくつか見てみましょう:「アプリケーションの負荷分散 (Application Load Balancing)」- 去年は「アプリケーションロードバランサー (application load balancer)」のサポートを追加しました。この高性能なロードバランシングオプションはアプリケーションレベルで実行され、コンテンツベースのルーティングルールで定義することができます。ダイナミックポートをサポートし、複数のサービスでの共有が可能なため、コンテナ内でマイクロサービスを実行しやすくなります。詳細については「サービスロードバランシング (Service Load Balancing)」をご覧ください。

タスクで使用する IAM ロール – ECS タスクに IAM ロールを割り当てることでインフラストラクチャを安全にできます。これにより、各タスクごとに細かく設定しアクセス許可を付与できるので、各タスクが必要とするアクセス許可を割り当てることが可能です。詳しくは「タスクで使用する IAM ロール (IAM Roles for Tasks)」をご覧ください。

サービス Auto Scaling – 需要の変化に応じるため、サービス (タスク) のスケールダウンやスケールアップに関するスケーリングポリシーを定義できます。お客様は必要なタスクの最小数および最大数を選択し、1 つまたはそれ以上のスケーリングポリシーを作成するのみです。あとはサービス Auto Scaling で処理されます。この機能を活用するには「サービス Auto Scaling (Service Auto Scaling)」をご覧ください。

Blox – コンテナベース環境の Scheduling は、インスタンスにタスクを割り当てる際のプロセスです。ECS は 3 つのオプションを提供します: 自動 (すでに組み込まれている サービススケジューラー)、手動 (RunTask 関数を使用)、カスタム (ご自分で提供するスケジューラーを使用)。Blox は one-task-per-host タイプをサポートするオープンソーススケジューラーです。今後、他のタイプにも対応する可能性も充分にあります。これはクラスターの状態を監視し、モニタリングエージェントやログコレクター、その他のデーモンスタイルのタスクを実行するのに適しています。

Windows – Linux コンテナをサポートする ECS をリリースしたほか Windows Server 2016 Base with Containers の実行もサポートするようになりました。

コンテナインスタンスのドレイン – クラスターをスケールダウンしたりシステムを更新するために、実行中のクラスターからインスタンスを削除することが必要な場合も時にはあるでしょう。インスタンスの状態をより管理しやすくするため、今年始めに一連のライフサイクルフックを追加しました。ライフサイクルフックと Lambda 関数を使用して、新しい作業にスケジュールを設定することなく、インスタンスから既存の作業のドレインプロセスを自動化する方法については「Amazon ECS でコンテナインスタンスのドレインを自動化する (How to Automate Container Instance Draining in Amazon ECS)」をご覧ください。

コードを使用した CI/CD パイプライン* – コンテナはソフトウェアの導入を簡素化し、CI/CD (継続的インテグレーション / 継続的デプロイメント) パイプラインにとって理想的なターゲットです。過去に公開したブログ「AWS CodePipeline、AWS CodeBuild、Amazon ECR、AWS CloudFormation を使用し Amazon ECS で行う継続的デプロイメント (Continuous Deployment to Amazon ECS using AWS CodePipeline, AWS CodeBuild, Amazon ECR, and AWS CloudFormation)」では、複数の AWS サービスを使用して CI/CD パイプラインを構築し動作させる方法について説明しています。

CloudWatch Logs の統合 – このリリースでは、一元管理と分析に使用する CloudWatch Logs にログ情報を送信するタスクを実行するコンテナ設定が可能になりました。Amazon ECS コンテナエージェントをインストールし awslogs ログドライバーを有効にするだけです。CloudWatch Events – タスクの状態またはコンテナインスタンスが変更すると、ECS は CloudWatch Events を生成します。こうしたイベントは Lambda 関数を使用してクラスターの状態を監視できるようにします。Elasticsearch クラスターでイベントをキャプチャし保存する方法については「Amazon ECS Event Stream でクラスターの状態を監視する (Monitor Cluster State with Amazon ECS Event Stream)」をご覧ください。

タスク配置のポリシー – このリリースでは、クラスター内のコンテナインスタンスでタスク配置における細かな管理設定を提供しました。クラスター制約、カスタム制約 (場所、インスタンスタイプ、AMI、属性)、配置戦略 (スプレッドまたはビンパック) を含むポリシーを作成し、コードを作成することなく使用できるようにします。詳細については「Amazon ECS タスク配置のポリシー (Introducing Amazon ECS Task Placement Policies)」をご覧ください。

EC2 Container Service の実行
金融サービス、ホスピタリティ企業、家電メーカーなど様々な分野における大規模なエンタープライズから急成長中のスタートアップ企業まで、AWS をご利用のお客様は Amazon ECS を使用して独自のマイクロサービスアプリケーションを本稼働環境で使用しています。Capital One、Expedia、Okta、Riot Games、Viacom といった企業は Amazon ECS に依存しています。

Mapbox は、カスタムマップを設計し公開するプラットフォームです。同企業は ECS を使用してバッチ処理のアーキテクチャをサポートし、マップのサポートに使用する 1 億マイルのセンサーデータを毎日収集し処理しています。スポットインスタンスを使用して ECS でバッチ処理アーキテクチャの最適化も行います。Mapbox のプラットフォームは 5,000 件以上のアプリをサポートし、毎月 2 億人以上のユーザーをターゲットにしています。そのバックエンドは ECS で実行され、毎日 13 億件のリクエストに対応しています。同社が最近行った ECS への移行に関する詳細は「Amazon ECS に切り替えるメリット (We Switched to Amazon ECS, and You Won’t Believe What Happened Next)」をご覧ください。

旅行会社の Expedia は、マイクロサービスアーキテクチャで同社のバックエンドを設計しました。Docker の普及に伴い、スピードのあるデプロイメントや環境の可搬性に Docker を取り入れることにしました。ALB から IAM ロール、VPC の統合まで、優れた統合性を備えているため、すべてのコンテナ調整に ECS を使用することにしました。これにより、既存の AWS インフラストラクチャで ECS がとても使いやすくなりました。ECS により、デプロイやコンテナ化されたアプリケーションの負担を軽減できるようになりました。Expedia はすべてのアプリケーションのうち 75% を ECS の AWS で実行し、毎時間 40 億件のリクエストを処理できるようにしています。詳しくは Kuldeep Chowhan のブログ「Amazon ECS を使用して本稼働環境で Expedia が何百件ものアプリケーションを実行している方法 (How Expedia Runs Hundreds of Applications in Production Using Amazon ECS)」をご覧ください。

Realtor.com は住宅の購入販売において現在売りに出されている不動産物件の包括的なデータベースを提供しています。同社が AWS に移行してから ECS を使用することでサポートビジネスが成長し、現在では毎月の閲覧者数が 5,000 万人を超え、ピーク時には毎秒 250,000 件のリクエストが記録されています。ECS は同社がクラウドインフラストラクチャの使用率を高めながら、よりすばやくコードをデプロイすることをサポートしています。同社が ECS、Kinesis、その他の AWS サービスをどのように活用しているかは「Realtor.com の導入事例 (Realtor.com Case Study)」をご覧ください。Instacart は、食品同日配送サービスのサポートに ECS をどのように利用しているのか説明しています:

Capital One は、ECS を使用してオペレーションやインフラストラクチャの管理を自動化しているのか説明しています:

Code Clever の開発者は ECS を独自の作業ベースに使用しています。例: Rack はオープンソースの PaaS (Platform as a Service) です。これは分離されている VPC で実行するインフラストラクチャの自動化に集中し、セキュリティにはシングルテナントで構築されたサービスを使用します。

Empire もオープンソース PaaS です。Heroku のようなワークフローを提供し、マイクロサービスに重点を置いた小規模および中規模のスタートアップ企業をターゲットにしています。Cloud Container Cluster Visualizer (c3vis) は、ECS クラスター内でリソースの使用率を可視化します:

今後もお楽しみに!
この他にも ECS の新機能を構築中です、乞うご期待ください!

Jeff;

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

 

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に関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。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スケールアウト

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各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 河原が担当しました。原文はこちらです。

AWS X-Ray で AWS Lambda をサポート

本日、AWS X-RayAWS Lambda サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。

複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。

今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。

または AWS Command Line Interface (CLI) で関数の tracing-config を更新してください (必ず --function-name も忘れずに):

$ aws lambda update-function-configuration --tracing-config '{"Mode": "Active"}'

トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。

X-Ray デーモンは Lambda 関数のいくつかのリソースを使用することがあります。メモリ制限に近付いている場合、Lambda はメモリ不足エラーを回避するために X-Ray デーモンを終了しようとします。では、複数のサービスを使用する簡単なアプリケーションを構築して新しい統合を試してみましょう。


20 代が持つスマートフォンということで、 pictures 自分のスマホは自撮りの写真でいっぱいです (10000+!)。ということで、この機会に写真をすべて分析してみることにしました。Java 8 ランタイムを使用して、Amazon Simple Storage Service (S3) バケットにアップロードした新しい画像に反応するシンプルな Lambda 関数を作成します。写真には Amazon Rekognition を使用し、検出したラベルを Amazon DynamoDB に保存します。

サービスマップ

まず、X-Ray のボキャブラリーをいくつか確認しておきましょう: サブセグメントセグメントトレースです。 分かりましたか? サービスグラフを生成するために X-Ray が処理するトレースをサブセグメントとセグメントが構成している、ということを覚えておけば X-Ray を理解しやすいと思います

サービスグラフは見やすいビジュアル表現を提供します (様々なリクエストへの応答を別の色で表示)。アプリケーションロジックを実行しているコンピューティングリソースは、実行している作業に関するデータをセグメント形式で送信します。サブセグメントを作成すれば、データに関する注釈を追加したり、コードのタイミングをより細かく設定することができます。アプリケーションを経由するリクエストのパスは、トレースを使用して追跡されます。トレースでは、1 つのリクエストで生成されたセグメントをすべて収集します。つまり、S3 からの Lambda イベントを DynamoDB まで簡単に追跡することができるので、エラーやレイテンシーがどこで発生しているか把握することができます。

では、S3 バケットを作成してみましょう。このバケットの名称は selfies-bucketにします。DynamoDB テーブルは selfies-table、あとは Lambda 関数です。ObjectCreated で S3 バケットの Lambda 関数にトリガーを追加します。Lambda 関数コードは実にシンプルです。こちらでご覧ください。コードの変更なしに、JAR の aws-xray-sdk と aws-xray-sdk-recorder-aws-sdk-instrumentor パッケージを含むことで Java 関数で X-Ray を有効にすることができます。アップロードした写真をいくつかトリガーして X-Ray のトレースを見てみましょう。

データが取れました!トレースの 1 つをクリックすれば呼び出しの詳細情報を見ることができます。

最初の AWS::Lambda セグメントでは、関数のドウェル時間、実行待機時間、試行された実行数を見ることができます。次の AWS::Lambda::Function セグメントにはいくつかのサブセグメントが見られます。

  • 初期設定のサブセグメントには関数ハンドラが実行する前の時間すべてが含まれます。
  • アウトバウンドサービスコール
  • 任意のカスタムセグメント (簡単に追加可能)

どうやら DyamoDB 側で問題が発生しているようです。エラーアイコンをクリックすれば、より詳しい情報と例外のスタックトレースを見ることができます。書き込みキャパシティーユニットが不足しているので、DynamoDB に調整されたことが分かります。数回のクリックまたは簡単な API コールで追加できます。そうするとサービスマップに表示される緑が増えていきます。

X-Ray SDK は X-Ray へのデータ放出をとても簡単にしますが、トークに X-Ray デーモンを使用する必要はありません。Python を使用している場合は fleece という rackspace からライブラリを確認できます。X-Ray サービスは興味深いものをたくさん備えています。詳細については「未定義 ()」ドキュメントをご覧ください

個人的に @awscloudninja ボットで使用していますが、これはとても優れていると思います。ただし、これは公式のライブラリではなく AWS がサポートしていない点にご留意ください。時間節約、デバッグや操作に対する労力においても便利なので、個人的には今後のプロジェクトすべてで X-Ray を使う予定です。皆さんがどのように構築するのか楽しみにしています。使えそうなトリックやハックを見つけたら、ぜひお知らせください!

– Randall

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

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

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は深層学習のパートナーシップを拡大させました

今年の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岩永)