Author: AWS Japan Staff


暗号化を用いたセキュアな Amazon EMR

ここ数年で、エンタープライズ企業において Apache hadoop エコシステムを用いて、センシティブであったり、きわめて秘匿性が高かったりするデータを扱う、重要なワークロードを走らせるケースが非常に増えてきています。そうしたワークロードの特性により、エンタープライズ企業ではしっかりした組織/業界全体のポリシーや、規制、コンプライアンスのルールを定めています。それに基づいて、機密データの保護や、権限のない人がアクセスできないようにすることが求められています。

こうしたポリシーにおいては一般的に、データストアに保存されているとき、そしてデータを転送しているときの両方で暗号化が要求されます。Amazon EMR では “セキュリティ設定” を使うことで、AWSキーマネジメントサービス (KMS) からお客様自身が用意した暗号化要素まで、さまざまな暗号化キーや証明書を指定することができます。

暗号化設定についてのセキュリティ設定を作り、クラスター作成の際に、その設定を当てることができます。セキィリティ設定を一度作っておくことで、いくつものクラスターにその設定を簡単に適用可能です。

o_Amazon_EMR_Encryption_1_

この投稿ではEMRのセキュリティ設定による、複数段階のデータ暗号化のセットアッププロセスを概観します。暗号化について深く見ていく前に、データ暗号化が必要な状況を整理しましょう。

保存時のデータ

  • Amazon S3にあるデータ – EMRのS3クライアントサイド暗号化
  • ディスク上のデータ – Linux Unified Key System (LUKS) による、Amazon EC2 のインスタンスストアボリューム(ブートボリュームを除く)、クラスターインスタンスにアタッチされた Amazon EBS
    ボリューム

転送中のデータ

  • EMRからS3に転送中のデータ、またはその逆 – EMR の S3 クライアントサイド暗号化
  • クラスター内のノード間で転送中のデータ – Secure Socket Layer (SSL) による MapReduce の in-transit 暗号化と、Simple Authentication と Security Layer (SASL) による Spark の shuffle 暗号化
  • ディスクに溢れたデータ、またはシャッフルフェーズの最中にキャッシュされたデータ – Spark の shuffle 暗号化、またはLUKS 暗号化

暗号化の手順

この投稿のために、転送中、保存時の暗号化に使うためのセキュリティ設定を作りましょう。

  • EMRやS3にあるデータに対して、LUKS 暗号化やS3 クライアントサイド暗号化のための KMS キー
  • MapReduce のshuffle 暗号化で使用する SSL 証明書
  • EMR クラスタが立ち上げられる環境。プライベートサブベットで EMR を立ち上げて、S3 からデータを取得するための VPC エンドポイントを設定します
  • EMR セキュリティ設定

この手順で説明するすべてのスクリプトとコードスニペットは、aws-blog-emrencryption Github レポジトリから取得できます。

KMS キーの生成

この手順では鍵管理について、データやディスクを暗号化するために使用する暗号化キーを、簡単に生成、管理できるマネージドサービスの、AWS KMS を使用します。

2つの KMS マスターキーを生成します。ひとつは EMR外のデータを暗号化する S3 クライアントサイド暗号化キーとして、もうひとつはローカルディスクを暗号化するための LUKS 暗号化のキーとして使用します。 Hadoop MapReduce フレームワークは HDFS を使用します。Spark は、ワークロードの中でメモリから溢れた中間データを一時的に保存する先として、各スレーブインスタンスのローカルファイルシステムを使用します。

鍵を生成するために、kms.json という AWS CloudFormation スクリプトを使用します。スクリプトの中で、キーの エイリアス名またはディスプレイ名を指定します。エイリアスは “alias/エイリアス名” 形式で、エイリアス名はアルファベット、アンダースコア、ダッシュのみで構成される必要があります。

o_Amazon_EMR_Encryption_2

キーの作成が終わったら、Outputs として ARN が表示されます。

o_Amazon_EMR_Encryption_3

SSL 証明書の作成

SSL 証明書によって、Mapreduce のシャッフル中にデータがノード間を転送されるときに、データの暗号化が行われます。

o_Amazon_EMR_Encryption_4

この手順では、OpenSSL で 2048-bit RSA 秘密鍵による X.509 自己署名証明書を作成します。これを使って EMR クラスタのインスタンスにアクセスします。画面に従って、証明書発行に必要な情報を入力します。

cert-create.sh を使って、zip ファイルに圧縮した SSL 証明書を生成します。zip 圧縮済みの証明書を S3 にアップロードし、S3 のプレフィックスをメモしておきます。セキュリティ設定を構成するときには、この S3 プレフィックスを使用します。

重要
この例は、あくまで proof-of-concept のデモにすぎません。自己署名証明書を使うことは推奨されませんし、潜在的なセキュリティリスクを孕みます。実運用システムでは、信頼できる認証局が発行した証明書を使ってください。

カスタムプロバイダの証明書には、TLSArtifacts プロバイダインタフェースを使用してください。

環境の構築

EMR クラスタをプライベートサブネットに構築します。もしすでに VPC があり、パブリックサブネットにクラスターを立てたい場合には、このセクションを飛ばして、セキュリティ設定の作成のセクションに進んでください。

クラスターをプライベートサブネット内に立てるためには、以下のリソースが必要です。

  • VPC
  • プライベートサブネット
  • パブリックサブネット
  • 踏み台サーバ
  • マネージド NAT ゲートウェイ
  • S3 VPC エンドポイント

EMR クラスターをプライベートサブネットに立てる際には、クラスターに SSH で入るための踏み台サーバかジャンプサーバが必要になります。クラスターの起動が終わったら、KMS からデータキーを取得するためにインターネットに接続する必要があります。プライベートサブネットからは直接インターネットに接続できないので、マネージド NAT ゲートウェイ経由でトラフィックの経路を制御します。S3 に対して、高信頼性を確保して安全に接続するために、S3 VPC エンドポイントを使用します。

o_Amazon_EMR_Encryption_5

CloudFormation コンソールで、environment.json テンプレートを使って、環境構築用の新しいスタックを作成します。

パラメタとして、踏み台サーバのインスタンスタイプと、そのサーバに SSH アクセスするための EC2 キーペアを入力します。適切なスタック名とタグを指定します。例えば、私の作成したスタックのレビューステップのスクリーンショットは、以下の通りになります。

o_Amazon_EMR_Encryption_6

スタックの作成が終わったら、Outputs タブを開いて VPC、踏み台サーバ、プライベートサブネットのIDをメモしておきます。これらはあとで EMR クラスタを立ち上げる際に使用します。

o_Amazon_EMR_Encryption_7

セキュリティ設定の作成

セキュアな EMR クラスタを立ち上げる前の最終ステップは、セキュリティ設定の構成です。EMR の S3 クライアントサイド暗号化と、先ほど作成した KMS キーを用いたローカルファイルの LUKS 暗号化について、セキュリティ設定を作成します。さらに MapReduce のシャッフルで暗号化を行うために、先ほど作成して S3 にアップロードしておいた SSL 証明書も使用します。

o_Amazon_EMR_Encryption_8

EMR クラスターの立ち上げ

さて、これでプライベートサブネットに EMR クラスタを立ち上げることができるようになりました。まずサービスロールとして、サービスポリシー内の AmazonElasticMapReduceRole が EMR に割り当てられていることを確認します。デフォルトのサービスロールは EMR_DefaultRole です。詳しくはIAMロールを使用したユーザーアクセス権限の設定を参照してください。

環境の設定セクションでメモしておいた VPC ID とサブネット ID の中で、EMR クラスタを立ち上げます。Network EC2 Subnet フィールドで、それらの値を選択してください。続いてクラスタの名前とタグを入力します。

o_Amazon_EMR_Encryption_9

最後のステップはプライベートキーの選択です。ここでは、セキュリティ設定の作成セクションで作っておいたセキュリティ設定を適用します。そして Create Cluster をクリックします。

o_Amazon_EMR_Encryption_10

これで作成した環境の上で、クラスタが立ち上がりました。続いてマスターノードに入ってスクリプトを実行します。EMR コンソールページからクラスタの IP アドレスを取得します。HardwareMaster Instance Group と選択して、マスターノードのプライベート IP アドレスをメモします。

o_Amazon_EMR_Encryption_11

マスターノードはプライベートサブネット内にあるので、まず踏み台サーバに SSH で入り、そこからさらにマスターノードに接続します。踏み台サーバと Hadoop マスタへの SSH については、ssh-commands.txt ファイルをみてください。踏み台サーバへのアクセスについてのさらなる詳細は、Securely Connect to Linux Instances Running in a Private Amazon VPC のエントリーを参照してください。

マスターノードに入った後は、Hive や Spark のスクリプトを実行します。動作確認用として、GitHub /code ディレクトリには PySpark の test.py と Hiveの test.q スクリプトが含まれています。

まとめ

この投稿の中で、データの暗号化が必要な複数のパターンについて述べ、各パターンでどうやって暗号化するかについての手順を説明しました。そして暗号化の前提要件である KMS キーの作成、SSL 証明書の発行、強力なセキュリティ設定による EMR クラスタの立ち上げについて、順を追って解説しました。そして VPC 内のプライベートサブネットでのクラスター起動によって、データをセキュアに
保つとともに、EMR クラスターにアクセスするために踏み台サーバを活用することができました。

もし疑問や助言があれば、ぜひおしらせください。

(翻訳はSA志村が担当しました。原文はこちら

今すぐ利用可能に – Lumberyard Beta 1.7

Lumberyardをローンチしてから1年も経っていないとは信じられません。お客様の反応とLumberyardとのエンゲージメントは私たちの期待を超えており、2017年にはお客様の進展を加速させることができて非常に興奮しています。Cloud Imperiumのような業界で最も野心的な開発者を含むあらゆるタイプのゲーム開発者から、信じられないほどつながっている世界を築いています。今日では、発売以来の最大のリリースで新年を始めることができて嬉しく思っています。 Lumberyard Beta 1.7には、403以上の新機能、改善点、修正点が含まれており、ここからダウンロードできます。

今回のリリースでは好きなことがたくさんあります。Lumberyardを使いやすくし、プロフェッショナルなゲーム開発者がもっと使いやすいようにするために、いくつかのアップデートをお伝えしたいと思います。私たちのチームはアクセシビリティについて考えており、チームの洗練さや品質、チームの規模や構成にかかわらず、私たちの選択肢があなたのビジョンを達成することを決し妨げないようにしたいと考えています。 アクセシビリティを測定する最も重要な方法の1つは、「顧客がどれくらい迅速に資産を取得して再利用できるのか」という問題です。ゲーム開発者にとって最も反復的なタスクの1つは、プロジェクト資産の作成と管理です。アーティスト、デザイナー、ゲームプレイエンジニアにとっては、1日に数百回から数千回の時間がかかるため、アセットを数秒で処理することができれば、チームのスピードに大きな違いが生まれます。加速を達成するための当社の戦略は、LumberyardのAsset Processorと、Lumberyard Beta 1.7を初めて導入したAsset Browserです。資産プロセッサーを使用すると、資産をほぼすぐにエンジンに取り込むことができます。ファイル(MayaやPhotoshopなど)をフォルダに保存するだけで、Asset Processorはそのファイルをソースアートからゲーム用アセットに自動的に処理します。元に戻ってアセットを編集すると、Lumberyardは変更を認識し、バックグラウンドで数秒で自動的に更新します。

1.7での新しいLumberyard Asset Browser Previewを使用すると、エディタ内の使い慣れたビューで使用可能なすべてのアセット(エディタ、Gem、プロジェクトフォルダ内のソースフォルダとファイルを含む)を表示し、シーン内のアセットをドラッグ&ドロップできます。エディタからワンステップでソース資産にアクセスすることができれば、特にプロジェクトで複数の出力を生成できる複雑なソースアセット(たとえば、メッシュとマテリアルの両方を含む単一の.fbxファイル)を使用する場合は、処理速度が大幅に向上します。また、Lumberyard Asset Processorを使用して、資産が変更、削除、または追加されると、新しい資産ブラウザが自動的に更新されます。 Asset Browserの基礎となるAPIはLumberyardバスシステムに公開されているので、独自のプラグインやコントロールを作成している場合は、ファイルサイズ、名前、場所、資産を作成したソース、資産などの豊富な情報にアクセスできます。他のどの資産が同時に生産されたか アクセシビリティについて考えるもう一つの方法は、Lumberyardエディタ自体のレイアウトと情報アーキテクチャです。 Lumberyard Editorには、基本的な編集者や照明ツールなどのさまざまな機能があり、ジャンル固有のツール(道路や川のツールなど)があります。時間の経過とともに自然に成長するフィーチャの量は、効率的に整理されていなければ、学習することが難しくなります。さらに、両方のゲームチームが新しい専門的な役割を創り出し、DCCツールが進化するにつれ、ベストプラクティスは長年にわたって進化しています。このため、Lumberyard Beta 1.7では、最高品質の、最も野心的なゲームを構築するための機能を失うことなく、Lumberyardのアクセシビリティを向上させるために、Editor Editorのコアに加えたいくつかの変更点をご紹介します。デフォルトのエディタレイアウト自体は少し違って見えます:

lumberyard-editor-1.7-1024x610

(以前のバージョンのLumberyardをインストールしている場合は、現在のレイアウトを上書きしませんが、[View – Layouts – Component Entity Layout]を選択して新しいレイアウトに切り替えることができます)

上記の内容は、Editor UXの改良の第1段階です。私たちは、社内外の多くのゲーム開発者にインタビューし、新しいコンポーネントエンティティシステムと顧客からのフィードバックを基にしたメインエディタインタフェースの再構成と合理化を開始しました。以前はゲームオブジェクトを作成するために、12種類のオブジェクトタイプの中から選択し、ロールアップバーの複数のレイヤーをナビゲートしてカスタマイズしなければなりませんでした。今では、単純な右クリックで作成できるゲームエンティティの1つのタイプとなりました。エンティティのコンポーネントを編集し、そのエンティティで使用するファイルを選択し、すべてのレベルのエンティティを切り替えるのは、すべてメインウィンドウで行われます。エンティティのネストされたプレハブ(「スライス」)を簡単に作成することもできます。メインウィンドウを右クリックするだけです。

次にUXチームのリストでは、ツールバーとトップメニューを合理化しながら、自分の役割や好みに基づいてレイアウトを深くカスタマイズすることができます。私たちは、顧客からより多くのデータとフィードバックを収集しています。あなたがアイデアを持っているなら、それについて聞きたいのです。フォーラムで、私達がどこに向かうのかのプレビューをご覧ください。
モバイルデベロッパーにとって、「使いやすい」とは、可能な限り短時間でエディターからデバイスにゲームを展開できることを意味します。そのため、ゲームを編集してから再生することができます。 Lumberyard Beta 1.7には、エディタに新しいデプロイメントツールが含まれているため、ワンクリックでエディタからAndroidデバイスにリリース、プロファイル、またはデバッグビルドをわずか数秒で展開できます。以前は、エンジニアはコマンドラインツールのみを使用してモバイルビルドを導入する必要がありました。これで、チームの誰もがAndroidビルドをエディタからデバイスに展開できます。
私たちのチームは、エディタをより使いやすくすることでより速く反復できるようにすることに加えて、マルチプレイヤーゲームをより簡単に作成できるようにするために多くの時間を費やしています。PCとコンソールゲームの上位80%がマルチプレイヤーをフィーチャーし、Twitchでストリーミングされるトップゲームの90%がマルチプレイヤーゲームです。だから、他のエンジンよりもマルチプレイヤーを簡単にするためのシステムとサービスをリリースしても、ゲーム開発者からの肯定的なフィードバックを引き続き得ることは驚くことではありません。この目的のために、私たちのネットワークチームは、コンポーネントエンティティのワークフローと高性能なネットワークレイヤ、GridMateを使用して完全に構築された新しいマルチプレイヤーサンプルをリリースしました。GridMateは効率的な帯域幅使用と低遅延通信を目的として設計されています。 30分以内に、新しいサンプルを起動して実行して、自分のマルチプレイヤーゲームやプロトタイプの出発点として使用できます。サンプルは現在PCをサポートしており、すぐにモバイルプラットフォームとコンソールプラットフォームをサポートするようにサンプルを拡張します。

AresScreenshotHighRes-1024x587

これらの例は、Lumberyardを世界最高クラスの使いやすいエンジンにするための、我々が継続的に行った変更のサンプルです。それは、我々はちょうど始まっていると言いました。業界の進化に伴い、より多くの人々がプレイし、ファンはさらに高品質のコンテンツを要求しています。私たちはあなたの能力が向上し、最も野心的なビジョンを達成し、ファンの愛するゲームを構築します。エンジニア、アーティスト、ゲームデザイナー、またはまだ発明されていない新しい役割を持つことができます。 Visual Studio 2015のサポート、VRの球面ビデオ再生のサポート、Perforce Helixとの統合、Geppetto文字ツールのUXの改良、オーディオ、照明、複合図形、アニメーションをサポートする新しいコンポーネントエンティティなど、このアップデートにはさらに多くのものがあります。 Twitch ChatPlayとMetastreamのアップデート、最新のAWS 1.0.24 SDKとの統合などが含まれます。 Lumberyard Beta 1.7の新機能の詳細については、こちらのリリースノートを参照してください。

Amazon Lumberyardを使い始めるには、LumberyardのウェブサイトでLumberyardをダウンロードしてください。 Lumberyardの新機能について詳しくは、チュートリアルフォーラムドキュメントを参照してください。

(翻訳はSA 森が担当しました。原文はこちら)

Amazon WorkSpaces の更新 – SSD ボリュームとコストオプティマイザ

長い間ブログをお読みいただいているお客様は、私が Amazon WorkSpaces を非常に気に入ってフルタイムで使用していることをご存知かと思います (詳細については、「Amazon WorkSpace がお気に入りです!」を参照してください)。さまざまなデバイスウェブブラウザからアクセスできる単一の環境があることにより、作業に集中し、多くの問題を軽減することができます。本日は、SSD ボリュームと WorkSpaces 用の新しいコストオプティマイザについてご紹介します。

新しい SSD ボリューム
本日より、新しく起動されたすべての Amazon WorkSpaces では、ルートボリュームおよびユーザーボリューム用に汎用 SSD ストレージが追加料金なしで使用されます。これらのボリュームにより、マグネティックボリュームよりもパフォーマンスが向上するため、ディスクのレイテンシーの影響を受けるアプリケーションを実行するときに、より高速な起動時間とより良いユーザーエクスペリエンスが得られます。既存の WorkSpaces は、再構築してストレージに SSD ボリュームを使用するようアップグレードすることができます (これにより、システムドライブ (C:) は元の状態にリストアされ、最新の自動スナップショットのコンテンツを使用してデータドライブ (D:) が再作成されます)。システムドライブの既存データはすべて失われます。新しい SSD ボリュームの追加料金はなく、Amazon WorkSpaces が運用されているすべてのリージョンで利用できます (両方の詳細については、WorkSpaces の料金表ページを参照してください)。SSD ストレージの利点を得るため、コンソールから新しい WorkSpaces を起動できます。目的のバンドルを選択し、通常どおり作業を続行します。

WorkSpaces コストオプティマイザ
当社のお客様は、Amazon WorkSpaces を多くの異なる方法で使用しています。単一の組織内でフルタイムで使用するお客様もいれば、移動中や特定のプロジェクトでパートタイムで使用するお客様もいます。WorkSpaces では、お客様のニーズを満たすため、時間別および月別の請求オプションと、必要に応じてそれらを切り替える機能を提供しています。新しい Amazon WorkSpaces コストオプティマイザでは、この柔軟性に基づき、WorkSpaces 使用量データを分析し、結果に基づいて最もコスト効果の高い請求オプションを自動的に適用します。コストオプティマイザは、AWS CloudFormation テンプレートを通じてデプロイされる AWS ソリューションとして提供されます。このソリューションでは、CloudWatch イベントCloudWatch ログAWS Lambda 関数、Amazon S3AWS Directory ServiceWorkSpaces API を含む、複数の異なる AWS のサービスや機能が利用されます。その概要を次に示します。

Lambda 関数は 1 日 1 回実行されます。ログデータを分析し、最もコスト効果の高い請求オプションを判断してから、ModifyWorkSpaceProperties 関数を呼び出してオプションを設定します。すべての変更は S3 バケットに記録されます。このソリューションはそのまま使用したり、お客様独自の環境に合わせてカスタマイズしたりできます。また、分解して、イベント、ログ記録、サーバーレスコード、および API の組み合わせを使用し、組織の効率を興味深い方法で高める方法を確認することも可能です。

Jeff;

AWS Samurai 2016 の発表

2016年は、前年に引き続きクラウドに移行するうえで障壁とされていた規制やコンプライアンスはなくなりつつあり、ますますクラウドの普及が加速した年でした。また、いかに早くITリソースの調達し、アプリケーション開発を俊敏に行うか、実現するためのサービスも多数発表され、メディアでもクラウドの活用事例を多数目にする機会があったかと思います。

今年も、日々クラウドの普及に大きな貢献をしていただいているJAWS-UG (Japan AWS User Group) の中から、AWS Samurai 2016 を発表いたします。AWS Samurai は、2011年12月から続いている制度で、2016年のユーザーコミュニティにおけるさまざまな継続的な活動において、ユーザーコミュニティの成長およびAWSクラウドの普及に大きく貢献または影響を与えた方々を Amazon Web Services (AWS) から認定させていただく制度です。

今年は下記の3名の方々を AWS Samurai として選出いたします。選出されたみなさま、おめでとうございます!

 赤塚 誠二 さん(JAWS-UG 山形支部) Facebook
海外にはJAWS-UGと同様、多くのユーザーグループがあります。その中でも、韓国およびシンガポールのユーザーグループとのミートアップなど、JAWS-UGおよび現地のユーザーグループのメンバーが交流する企画を立ち上げ、言語の異なる他地域との橋渡しを積極的に実施しました。また、ユーザーグループの参加メンバーが中心となり企画から実施までを進めるJAWS DAYS 2016の実行委員長としてチームをまとめ、1,000名以上が参加したコミュニティ主導の大型イベントを実現しました。今後もさらに海外との交流を深めていただき、ユーザーグループのメンバー同士の新たな出会いの機会や交流を通じて、AWSクラウドが世界中で広がるような活動につながっていく事を期待しています。

 吉田 真吾 さん(JAWS-UG 横浜支部) Facebook
新たなクラウドのアーキテクチャとして注目されているサーバーレスや開発効率を向上させるための関連フレームワークなど、インフラエンジニアやアプリ開発者向けのイベントや各種勉強会をオーガナイザーとして多くの仲間を集め、東京や大阪地域で積極的に企画および実施しました。また、JAWS-UG横浜をリブートし、次世代のコミュニティリーダーの発掘・育成など、ユーザーグループが今後さらに成長する為の施策を進めました。アプリ/ウェブデベロッパーやインフラエンジニアをはじめとした開発・運用に関わるエンジニアの方々にサーバーレスアーキテクチャを知ってもらい、サービスを活用してイノベーションを起こしてもらえるよう、今後もファンや仲間を増やす活動を進めていただきたいと思います。

 青木 由佳 さん(JAWS-UG 初心者支部) Facebook
初心者支部の運営をはじめ、JAWS-UGやAWSクラウド初心者に対して、各支部の活動、「学ぶ」ことの楽しさを、イベント、勉強会やSNSで積極的に情報発信しました。本業はマーケティング職ですが、エンジニアと一緒に何かを実現したいという思いの中、JAWS DAYSの運営や登壇し、クラウドの魅力を自分の視点からわかりやすく伝えています。また、JAWS-UG運営のコアメンバーのひとりとして、60を超える支部が実施する勉強会等の予定をとりまとめ、メール通知やイベントカレンダー表示など、活動のみえる化を実現しました。ユーザーコミュニティの活用法やエンジニア以外の方々がJAWS-UGに継続的に参加していただけるよう情報発信を続けていただきたいと思います。

 

2016年11月に米国ラスベガスで開催された学習型カンファレンス AWS re:Invent 2016 では、大小合わせて50以上もの新機能やサービスが発表されました。年間の発表数は1,000以上あり、2017年もイノベーションのスピードはますます加速していきます。AWSからも多くの情報提供とインパクトのある新機能やサービスを提供させていただき、人と人がつながり学習する場としてのJAWS-UGの成長をサポートしてまいります。

 

アマゾン ウェブ サービス ジャパン株式会社
マーケティング本部 シニアプロダクトマーケティングマネージャー
石橋

MXNet が Apache に参加します!

Matt Wood の投稿
当社は Alexa から Amazon Go まで Amazon のすべての領域でディープラーニングを広範に使用し、これまで多くのディープラーニングエンジンを試してきました。そして 1 つのエンジンがディープラーニングを実行するための最もスケーラブルで効率的な方法として出現しました。その理由により、Amazon のエンジンとして MXNet が選択されました。MXNet はオープンソースの最新鋭のディープラーニングエンジンであり、これにより開発者は高度なカスタム人工知能システムを構築することができます。

このようなシステムのトレーニングは、そのスケールとパフォーマンスにより、MXNet では著しく高速です。たとえば、よく使用される画像認識ネットワークの Resnet では、MXNet は他のエンジンと比較して 2 倍のスループットを実現し、同等のモデルを半分の時間でトレーニングできます。また、MXNet は数百の GPU にわたって線形に近いスケーリングを示しますが、他のエンジンのパフォーマンスでは、規模に見合った増加は見られません。

Amazon には重要なチームがあり、MXNet コミュニティと連携して、この進化に継続的に取り組んでいます。チームは MXNet に対して Apache Incubator に参加し、Apache Software Foundation のプロセス、財産管理、支援活動、およびコミュニティイベントを活用することを提案しました。幸い、この提案は受け入れられました。Apache MXNet への投資は開始点にあり、当社はコミュニティと連携して既に重要になっているユーティリティを拡大していくことを楽しみにしています。MXNet の使用開始を希望される場合は、AWS Re:Invent で私が行った基調講演をご覧になり、AWS ディープラーニング AMI のインスタンス (またはクラスター全体) を起動してください。これには MXNet と、プリコンパイルされ、すぐに使用できるサンプルコードが含まれています。また、推奨モデリングに関する Leo のプレゼンテーションとチュートリアルもご覧ください。

Twitter で @apachemxnet をフォローするか、オープンソースプロジェクトの更新について新しい Apache MXNet ページを参照してください。

AWS でホストされたアプリケーション用のユーザーネットワークから Amazon VPC への接続

AWS では非常に多くのことが起こっており、十分な知識に基づく決定や、計画プロセスの例のまとめ方について支援を求める声が読者の方々からよく寄せられています。本日は、Amazon Marketplace の上級カテゴリーリーダー Jim Carroll が、AWS Marketplace における AWS ネットワーキングサービスとソリューションについて説明します。

-Ana


先月、当社は新しいロンドンの AWS リージョンについて発表しました。この新しいリージョンは当社のグローバルインフラストラクチャを拡大し、コスト効果のあるスケーリングを行い、コンプライアンスおよびデータレジデンシー要件を満たすための、より多くの地理的オプションをパートナーやお客様に提供します。この発表は私の記憶に生々しいものです。というのも、AWS Marketplace の AWS ネットワーキングサービスとソリューションに関してお客様と最近行った会話の中で、お客様はこれを利用して企業ネットワークを AWS クラウドの仮想プライベートネットワークと接続しているというお話を聞いたからです。通常、お客様は、次のいずれかのビジネスニーズまたはその組み合わせをサポートするために、AWS でこのアーキテクチャをデプロイしています。

  • AWS クラウドにアプリケーションを継続して移行する
  • 離れた支社やリモート接続のために迅速かつコスト効果の高い方法でネットワークをスケールし、アプリケーションを AWS クラウドに移行中のエンドユーザーエクスペリエンスを向上させる
  • コンプライアンスおよびデータレジデンシー要件を満たす

本日は、このようなビジネスニーズを持つお客様が利用できる VPN オプションを概説し、意思決定を簡単に行えるよう支援します。Amazon VPC では、AWS が管理する VPN の設定、AWS Direct Connect でのプライベート回線接続の使用、および VPN 接続のための VPC でのサードパーティーネットワーキングソフトウェアの有効化が可能です。ユーザーがデスクトップまたはモバイルデバイスから直接 AWS にアクセスできるようにする、クライアントからサイトへの VPN を選択することもできます。Steve Morad の 2014 年のホワイトペーパーAmazon Virtual Private Cloud Connectivity Options」で、リモートネットワークから Amazon VPC への接続オプションの概要が説明されています。次の表は、これらの洞察と、AWS 上のお客様の仮想ネットワークで AWS が管理する VPN またはユーザーが管理するソフトウェア VPN エンドポイントを選択するうえでの考慮事項を示しています。この説明には、Morad のホワイトペーパーからの情報が含まれています。

ユーザーネットワークから Amazon VPC への接続オプション
AWS が管理する VPN インターネット経由の IPsec VPN 接続
AWS Direct Connect プライベート回線の専用ネットワーク接続
AWS Direct Connect + VPN プライベート回線の IPsec VPN 接続
AWS VPN CloudHub プライマリまたはバックアップ接続用のハブアンドスポークモデルでリモートの支社を接続
ソフトウェア VPN インターネット経由のソフトウェアアプライアンスベースの VPN 接続

AWS が管理する VPN
この手法により、自動化された複数のデータセンターの冗長性と、VPN 接続の AWS 側に組み込まれたフェイルオーバーを含む、AWS が管理する VPN エンドポイントの利点を活用できます。動的ルーティングと静的ルーティングのどちらも利用できるため、お客様側でフレキシブルにルーティング設定を行えます。図 1 にこれを示します。

図 1 - AWS が管理する VPN

AWS が管理する VPN の考慮事項:

  • ここに示してはいませんが、Amazon 仮想プライベートゲートウェイは 2 つの明確な VPN エンドポイントを表します。これらは別々のデータセンターに物理的に配置され、VPN 接続の可用性を高めます。
  • 動的ルーティングと静的ルーティングのどちらも利用できるため、お客様側でフレキシブルにルーティング設定を行えます。
  • 動的ルーティングは、ボーダーゲートウェイプロトコル (BGP) ピア接続による AWS とこれらリモートのエンドポイントとの間のルーティング情報の交換を強化します。
  • 動的ルーティングを使用すると、BGP アドバタイズメント内でルーティングの優先度、ポリシー、重みづけ (メトリクス) を指定し、お客様のネットワークと AWS 間のネットワーク経路を操作することができます。
  • 動的ルーティングを使用する場合、BGP 経由でアドバタイズされたルートは選択されたルーティングテーブルに伝達でき、新しいルートの AWS へのアドバタイズが容易になります。

ソフトウェア VPN
このオプションでは、リモートネットワークに接続する 1 つの Amazon EC2 インスタンスで実行するソフトウェア VPN アプライアンスを利用します。このオプションでは、ソフトウェアアプライアンス、設定、パッチ、およびアップグレードの管理を含む、Amazon VPC 接続の両面を管理する必要があります。 このオプションは、VPN 接続の両面を管理する必要がある場合にお勧めします。考慮事項:

  • コンプライアンス: この手法を、ハイブリッドネットワークアーキテクチャのコンプライアンスとデータレジデンシー要件に使用する必要が生じることもあります。IT セキュリティとプライバシーの規制によって特定の業界が管理され、ネットワークを含む IT インフラストラクチャは特定の政府標準規格を満たす必要があります。
  • ゲートウェイデバイスのサポート: 現在 Amazon が管理する VPN ソリューションによってサポートされていないゲートウェイデバイスを持っているお客様は、オンプレミスへの既存の投資を活用するため、ソフトウェア VPN のデプロイを選択してください。サポートされているゲートウェイデバイスのリストは、こちらにあります
  • AWS Marketplace のネットワーキングインフラストラクチャソリューション: オンプレミスネットワーキングインフラストラクチャソフトウェアは、AWS Marketplace の多くのソフトウェアベンダーからの事前設定済みでカスタマイズ可能な AMI を使用して簡単に拡大できます。

ソフトウェア VPN インスタンス用の HA アーキテクチャの例
ソフトウェア VPN インスタンス用の完全な復元力のある VPC 接続の作成では、複数の VPN インスタンスのセットアップと設定、およびインスタンスのモニタリングによる VPN 接続の状態の追跡が必要です。

図 3: HA 設計の概要

1 つのアベイラビリティーゾーンのすべてのサブネットから、同じアベイラビリティーゾーンの各 VPN インスタンスを通じてトラフィックをルーティングすることにより、すべての VPN インスタンスを同時に活用するよう VPC ルートテーブルを設定することをお勧めします。その場合、各 VPN インスタンスは同じアベイラビリティーゾーンを共有するインスタンスに VPN 接続を提供します。ホワイトペーパーでは、詳細情報と考慮事項を示しています。AWS MarketplaceBrocadeCisco などのベンダーからのネットワーキングインフラストラクチャソリューションを利用することで、オンプレミスシステムとクラウドへの既存の投資を最大限活用して、お客様固有のビジネス上の課題を満たすことができます。

-Jim Carroll

Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法

同僚のMadhuri Periが素晴らしい記事を書いてくれました。AutoScalingグループのクラスタをスケールダウンする際にインスタンスからタスクを事前に削除するために、コンテナ インスタンス ドレイニングを利用する方法です。

—–

Amazon ECSクラスタでは、クラスタからインスタンスを削除する必要があるタイミングというのがいくつかあります。例えば、システムを更新するとき、Dockerデーモンを更新するとき、あるいはクラスタのサイズをスケールダウンするときなどです。コンテナ インスタンス ドレイニング機能によって、クラスタ上のタスクに影響を与えることなく、コンテナインスタンスを削除することができます。この機能により、コンテナインスタンスがDRAINING状態である間はそのインスタンスに対して新しいタスクの配置がスケジュールされないようになり、利用可能なリソースがあればサービスがタスクをクラスタ上の他のコンテナインスタンスに移動してくれ、インスタンスを削除する前にタスクの移動が成功したことを待機できるようになります。

コンテナインスタンスの状態は、手動でDRAININGに変更することが可能です。しかしこの記事では、これらのプロセスを自動化するためにAutoScalingグループAWS Lambdaを利用してコンテナ インスタンス ドレイニングを行う方法を説明します。

Amazon ECS オーバービュー

Amazon ECSはコンテナ管理サービスです。クラスタやEC2インスタンスの論理グループ上でDockerコンテナの実行、停止、そして管理を容易にしてくれます。ECSを使ってタスクを実行するとき、タスクはクラスタに配置されます。Amazon ECSは指定されたレジストリからコンテナイメージをダウンロードし、そしてそのイメージをクラスタ内のコンテナインスタンス上で実行します。

コンテナ インスタンス ドレイニングの状態を扱う

AutoScalingグループはライフサイクルフックをサポートしています。ライフサイクルフックは、インスタンスの起動や削除の前に独自の処理を完了するために呼び出されます。今回の例では、ライフサイクルフックは、2つの処理を実行するLambdaファンクションを呼び出します。

  1. ECSコンテナインスタンスの状態をDRAININGに変更します。
  2. コンテナインスタンス上にタスクが1つも残っていないことを確認します。もしドレイニング中のタスクがまだ存在する場合は、Lambdaファンクションを再度呼び出すためにSNSにメッセージを送信します。

コンテナインスタンス上で実行中のタスクがなくなるか、あるいはライフサイクルフックのハートビートタイムアウト(サンプルのCloudFormationテンプレートではTTL15分に設定)に達するか、どちらかの状態になるまでLambdaによってステップ2が繰り返されます。その後、制御はオートスケーリングのライフサイクルフックに戻され、そのインスタンスは削除されます。このプロセスを次の図に示します。

Architecture

試してみましょう!

この記事で説明した一連のリソースをセットアップするためにCloudFormationテンプレートを使用します。このCloudFormationテンプレートを使用するには、あなたのアカウントのS3バケットにLambdaデプロイメントパッケージをアップロードする必要があります。このテンプレートは次のリソースを作成します。

  • VPCと関連するネットワーク要素(サブネット、セキュリティグループ、ルートテーブルなど。)
  • ECSクラスタ、ECSサービス、そしてサンプルのECSタスク定義
  • 削除のライフサイクルフックと2つのEC2インスタンスが設定されたAutoScalingグループ
  • Lambdaファンクション
  • SNSトピック
  • Lambdaを実行するために必要なIAMロール

CloudFormationスタックを作成し、インスタンスの終了イベントをトリガーすることによってどのようにこのスタックが機能するのか見ていきます。

Amazon EC2のコンソールにおいて、AutoScalingグループを選択し、CloudFormationによって作成されたAutoScalingグループの名前(CloudFormationテンプレートのリソースのセクションから)を選択します。

操作編集を選択し、インスタンスの希望の数を “1” に減らすようにサービスを更新します。これによって、2つのインスタンスのどちらか一方で終了プロセスが開始されます。

AutoScalingグループのインスタンスタブを選択します。1つのインスタンスのライフサイクルの状態が “Terminating:Wait” という値を示すはずです。

asg-draining
この状態になると、ライフサイクルフックが発火してSNSにメッセージが送信されます。そして、SNSメッセージトリガーに反応してLambdaファンクションが実行されます。

Lambdaファンクションによって、ECSコンテナインスタンスの状態がDRAININGに変更されます。その後、ECSサービススケジューラによってこのインスタンス上のタスクは停止され、利用可能なインスタンス上でタスクが起動されます。

ECSのコンソールに移動すれば、コンテナインスタンスの状態がDRAININGになっていることを確認できます。

ecs-draining
タスクが全て完了すると、AutoScalingグループのアクティビティ履歴でEC2インスタンスの削除を確認できます。

events-draining

どのように動作しているか

少しLambdaファンクションの内部的な動作を見てみましょう。ファンクションはまず最初に、受け取ったイベントのLifecycleTransitionの値が autoscaling:EC2_INSTANCE_TERMINATING にマッチするかをチェックします。

# もし受け取ったイベントがインスタンス終了中ならば・・・
if 'LifecycleTransition' in message.keys():
    logger.debug("message autoscaling %s",message['LifecycleTransition'])
    if message['LifecycleTransition'].find('autoscaling:EC2_INSTANCE_TERMINATING') > -1:

マッチする場合は “checkContainerInstanceTaskStatus” という関数が呼び出されます。この関数は、受け取ったEC2インスタンスIDのコンテナインスタンスIDを取得しコンテナインスタンスの状態を ‘DRAINING’ に変更します。

# ライフサイクルフックの名前を取得
lifecycleHookName = message['LifecycleHookName']
print("Setting lifecycle hook name {} ".format(lifecycleHookName))

# インスタンス上で実行中のタスクがあるかをチェック
tasksRunning = checkContainerInstanceTaskStatus(Ec2InstanceId)

続いてインスタンス上で実行中のタスクがあるかがチェックされます。実行中のタスクが存在する場合、このLabmdaファンクションを再度トリガーするためにSNSトピックにメッセージが発行され、このLambdaファンクションのプロセスは終了となります。

# タスクの詳細を得るためにタスクARNを使用
descTaskResp = ecsClient.describe_tasks(cluster=clusterName, tasks=listTaskResp['taskArns'])
for key in descTaskResp['tasks']:
    print("Task status {}".format(key['lastStatus']))
    print("Container instance ARN {}".format(key['containerInstanceArn']))
    print("Task ARN {}".format(key['taskArn']))

# 実行中のタスクがあるかチェック
if len(descTaskResp['tasks']) > 0:
    print("Tasks are still running..")
    return 1
else:
    print("NO tasks are on this instance {}..".format(Ec2InstanceId))
    return 0

Lambdaファンクションは、コンテナインスタンス上に実行中のタスクがない時には、ライフサイクルフックを終了しこのEC2インスタンスの削除に進みます。

# ライフサイクルフックの完了
try:
    response = asgClient.complete_lifecycle_action(
    LifecycleHookName=lifecycleHookName,
    AutoScalingGroupName=asgGroupName,
    LifecycleActionResult='CONTINUE',
    InstanceId=Ec2InstanceId)
    print("Response = {}".format(response))
    print("Completedlifecycle hook action")
except Exception, e:
    print(str(e))

 

まとめ

コンテナ インスタンス ドレイニングによって、クラスタのスケールダウンや新しいAMIのロールアウトのような運用業務がシンプルになります。例えばこの記事で説明された構成に加えて、CloudFormationやCodePipelineを利用して、新しいインスタンスの起動や終了を一括実行するローリングデプロイメントの環境を構築することもできます。

コンテナ インスタンス ドレイニングについてもっと知りたい場合は、Amazon ECS 開発者ガイドを参照してください。

ご質問やご提案があれば、ぜひ以下にコメントしてください。

(翻訳はSA畑が担当しました。原文はこちら)

 

Amazon クラウドディレクトリ – 階層データ用のクラウドネイティブなディレクトリ

当社のお客様は、これまでディレクトリ (一般的には Active Directory ライトウェイトディレクトリサービスや LDAP ベース) を使って階層別に整理されたデータを管理してきました。しばしば階層として表されるものには、デバイスレジストリ、コースカタログ、ネットワーク設定、ユーザーディレクトリがあり、同じコレクション内のオブジェクト間で複数のタイプの関係を持つ場合もあります。たとえば、ユーザーディレクトリは物理的な場所 (国、都道府県、市町村、建物、フロアー、オフィス) に基づいて 1 つの階層を持ち、プロジェクトや請求コードに基づいて 2 つ目の階層を持ち、管理チェーンに基づいて 3 つ目の階層を持つ場合があります。ただし、従来のディレクトリ技術では、単一のディレクトリ内で複数の関係の使用がサポートされません。これを行う必要がある場合は、追加のディレクトリを作成して管理する必要があります。もう 1 つの重要な課題として、スケールがあります。階層の基本的なオペレーションとして、特定のオブジェクトの親オブジェクトまたは子オブジェクトを見つける必要があります。その階層を使用して大規模なネストした情報のコレクションを表すことができる場合、この基本的なオペレーションは、オブジェクトの数やネストの深さにかかわらず、可能な限り効率的でなければなりません。従来のディレクトリはスケールが困難で、複数の階層を表すために 2 つ以上のディレクトリを使用する場合、苦労が増すばかりです。

新しい Amazon クラウドディレクトリ
本日、Amazon Cloud Directoryをリリースします。このサービスは、上記で説明したような、厳密に型指定された大量の階層データの保存に焦点を絞ったものです。コスト効率を維持しながら数億個のオブジェクトにスケールする機能により、Cloud Directory はあらゆる種類のクラウドおよびモバイルアプリケーションに最適です。Cloud Directory は、Amazon CognitoAWS Organizations を含む、他の AWS のサービスで既に利用されている構成要素です。これは AWS 内で非常に重要な役割を果たすため、スケーラビリティ、高可用性、およびセキュリティを考慮して設計されました (データは保管時および伝送中に暗号化されます)。Amazon Cloud Directory はマネージド型サービスであるため、ソフトウェアのインストールやパッチ適用、サーバーの管理、ストレージまたはコンピューティングインフラストラクチャのスケーリングについて考える必要がありません。スキーマを定義し、ディレクトリを作成してから、クラウドディレクトリ API を呼び出してディレクトリへの入力を行うだけです。この API は速度とスケールを実現し、効率的なバッチベースの読み書き関数を持つよう設計されています。ディレクトリの長期間使用できる特性に、運用期間中にサポートする必要があるユースケースのスケールや多様性を組み合わせることで、別の課題が明らかになります。経験によれば、静的スキーマはスケールと新しいユースケースによって生じる変更に対応する柔軟性に欠けることがわかっています。この課題に対応し、ディレクトリを将来にも十分対応できるようにするため、Cloud Directory は変更の余地を明確に残したモデルという概念に基づいて作成されています。新しいファセットを追加して、既存のスキーマを拡張します。これは既存のデータをそのまま残す安全なオペレーションであり、既存のアプリケーションは引き続き予期どおり動作します。スキーマとファセットを組み合わせることにより、同じディレクトリ内で複数の階層を表すことができます。たとえば、最初の階層では組織図をミラーリングするとします。後で、各従業員の追加のプロパティ (2 番目の電話番号またはソーシャルネットワークのハンドルなど) を追跡するために別のファセットを追加できます。その後、同じデータ内で地理指向の階層を作成できます (国、都道府県、建物、フロアー、オフィス、従業員など)。説明したように、AWS の他の部分では既に Amazon Cloud Directory を使用しています。Cognito ユーザープールCloud Directory を使用してアプリケーション固有のユーザーディレクトリを提供しており、ユーザーのサインアップ、サインイン、および多要素認証をサポートしています。Cognito ユーザープールでは、数億人のユーザーをサポートするようスケールするフルマネージ型のサービスにより、モバイルおよびウェブアプリに簡単かつ安全にサインアップおよびサインイン機能を追加できます。同様に、AWS OrganizationsCloud Directory を使用して関連する AWS アカウントグループの作成をサポートし、複数の階層を十分に活用して幅広いポリシーを適用します。詳しい内容を見る前に、Amazon Cloud Directory のいくつかの重要な概念を簡単に説明します。ディレクトリには名前が付けられ、少なくとも 1 つのスキーマが必要です。ディレクトリは、オブジェクト、オブジェクト間の関係、スキーマ、およびポリシーを保存します。ファセットは、必須の属性および許容される属性を定義してデータをモデル化します。各ファセットは属性名の独立したスコープを提供します。これにより、ディレクトリを共有する複数のアプリケーションは、衝突または混乱を恐れることなく、特定のスキーマを安全かつ独立して拡張できます。スキーマは、1 つ以上のファセットを参照して、ディレクトリに保存されたデータの「シェイプ」を定義します。各ディレクトリは複数のスキーマを持つことができます。スキーマは 3 つのフェーズ (開発、公開済み、適用済み) のいずれかに存在します。開発スキーマは変更でき、公開済みスキーマはイミュータブルです。Amazon Cloud Directory には、人、組織、およびデバイス向けに事前定義のスキーマのコレクションが含まれています。スキーマとファセットの組み合わせにより、初期データモデルおよび対象領域への経時変化に伴う重要な追加が可能になる一方で、既存のアプリケーションは引き続き予期どおり動作します。属性は実際に保存されたデータです。各属性には名前が付けられ、型付けされます。データ型にはブール、バイナリ (blob)、日時、数値、および文字列があります。属性は、必須またはオプション、およびイミュータブルまたは編集可能とすることができます。属性の定義では、保存または更新する前に属性の長さまたはコンテンツ、あるいはその両方を検証するために使用するルールを指定できます。バイナリおよび文字列オブジェクトは、最小および最大の長さに対して長さをチェックできます。ルールは、文字列にはリストから選択された値が必要であるか、または数値が特定の範囲内であるかを示すことができます。オブジェクトはディレクトリに保存され、属性を持ち、スキーマによって定義されます。各オブジェクトは、スキーマの指定により、複数の子と複数の親を持つことができます。複数の親機能を使用して、1 つのディレクトリ内で複数の独立した階層を作成できます (ツリーのフォレストとも呼ばれます)。ポリシーは階層の任意のレベルで指定でき、子オブジェクトによって継承されます。Cloud Directory はポリシーを解釈したり、意味を割り当てたりせず、この操作をアプリケーションに任せます。ポリシーを使用して、アクセス権限、ユーザー権限、デバイス特性などを指定、管理できます。

ディレクトリの作成
ディレクトリを作成しましょう。AWS Directory Service コンソールを開き、最初の [Create directory] ボタンをクリックします。

ディレクトリの名前 (users) を入力し、person スキーマ (偶然 2 つのファセットを持ちます。これについてはすぐに説明します) を選択して、[Next] をクリックします。

事前定義された (AWS) スキーマがディレクトリにコピーされます。これに名前とバージョンを指定し、[Publish] をクリックします。

次に設定を確認し、[Launch] をクリックします。

ディレクトリが作成され、コードを記述してそのディレクトリにオブジェクトを追加できます。

料金と可用性
Cloud Directory は、US East (Northern Virginia)US East (Ohio)US West (Oregon)Europe (Ireland)Asia Pacific (Sydney)、および Asia Pacific (Singapore) リージョンで利用でき、今すぐ使い始めることができます。料金は、保存するデータの量、読み取り数、および書き込み数という 3 つの要素に基づきます (以下の料金は US East (Northern Virginia) のものです)。

  • ストレージ – 0.25 USD / GB / 月
  • 読み取り – 10,000 回の読み取りあたり 0.0040 USD
  • 書き込み – 1,000 回の書き込みあたり 0.0043 USD

進行中
クラウドディレクトリに関しては大きな計画があります。お客様のフィードバックにより優先順位は変更される可能性がありますが、当社はクロスリージョンレプリケーション、AWS Lambda の統合、および AWS CloudFormation を介した新しいディレクトリの作成機能を開発中です。

Jeff;

AWS ホットスタートアップ – 2017 年 1 月

新年の始まりにあたり、再び Tina Barr が優れた多くのスタートアップ企業をさらに紹介します。ぜひご覧ください。

-Ana


本年も引き続き、AWS を利用しているホットなスタートアップ企業を紹介していきます。本日は、3 つの新しいスタートアップ企業を紹介します。

  • ClassDojo – 教師、児童生徒、親をクラスへとつなぎます。
  • Nubank – 銀行取引の概念を変える金融サービスのスタートアップ企業。
  • Ravelin – 機械学習モデルの上に構築された不正検出会社。

昨年の主なスタートアップ企業の紹介をまだお読みになっていない場合は、「1 年を振り返る」をぜひご覧ください。

ClassDojo (サンフランシスコ)
ClassDojo の画像2011 年に Liam Don 氏Sam Chaudhary 氏によって開始された ClassDojo は、クラス向けの通信プラットフォームです。教師、親、児童生徒は 1 日を通じて、写真、ビデオ、メッセージングを通じた重要な時間を共有するための場所としてこれを使用できます。今日、多くのクラスが万人向けのモデルとして運営されている中、ClassDojo の創設者は教育システムを改善し、世界中の 7 億人の初等教育の対象児童に、最善のコンテンツやサービスを受けさせたいと考えました。Sam と Liam が、クラスにとって何が最も役立つかを教師に質問したところ、多くの教師は、思いやりや寛容さのあるコミュニティが必要と答えました。つまり、クラスにかかわっている全員につながることができるコミュニティです。ClassDojo では、教師は児童生徒やその親と協力して独自のクラス文化を創造することができます。ClassDojo は 5 年で米国およびその他 180 か国の幼稚園から中学校までの 90% に拡大し、そのコンテンツは 35 か国語以上に翻訳されました。最近、ハーバード大学およびスタンフォード大学と共同作成された「Empathy and Growth Mindset」のビデオシリーズにより、さらに多くのクラスに拡大しました。これらのビデオは、米国の 14 歳以下の子どもの 3 人に 1 人は見ています。その作品の 1 つである Stories では、学校での写真やビデオの更新されたストリームを見ることができ、そのすべては家庭で親と共有されます。児童生徒は独自のストーリー (学習したことのタイムラインやポートフォリオ) を作成することもできます。ClassDojo は学校がある日や世界中の多くのタイムゾーンにおいて多用されているため、トラフィックパターンはかなり変化します。Amazon EC2 の Auto Scaling により、需要を満たす一方で、使用が少ない期間中のコストを管理することができます。このデータパイプラインは完全に AWS 上で構築されており、Amazon Kinesis により高ボリュームのデータを分析のため Amazon Redshift にストリーミングし、アーカイブのため Amazon S3 にストリーミングできます。また、Amazon AuroraAmazon RDS を利用して、重要な関連データを保存しています。これにより、保管時の暗号化を管理しやすくし、スケールして非常に低いレイテンシーで非常に高いクエリボリュームに対応しています。ClassDojo のすべてのウェブフロントエンドは Amazon S3 でホストされ、Amazon CloudFront を通じて提供されます。また、AWS WAF ルールを使用して、攻撃や許可されていないアクセスに対してフロントエンドを保護します。不正なアカウントを検出するために Amazon Machine Learning を使用し、新しい Amazon Lex サービスによりボイスコントロールを提供して、教師がクラスで製品をハンズフリーで使用できるようにすることを検討しています。世界中の教師がクラスで ClassDojo をどのように使用しているかを、同社のブログでご覧ください。

Nubank (ブラジル)
Nubank の画像Nubank は、ブラジルの銀行の常識を再定義しようと取り組んでいる、技術指向の金融サービスのスタートアップ企業です。創設者の David Vélez 氏と 350 人を超える技術者、科学者、設計者、分析者のチームが、世界で最も急速に成長中のモバイル市場の 1 つにおいて、これまでとは異なる銀行取引を作成しました。ブラジルは面積と人口の両方において世界第 5 位の国であるだけでなく、世界で最もクレジットカードの利率が高い国の 1 つです。Nubank は、あらゆる人がスマートフォンにアクセスできる世界においてクレジットカードの体験を定義し直し、これまでに顧客が見たことのない製品を提供しています。ブラジルの銀行業界は規制が厳しく、それと共にきわめて集中化されています。Nubank は真に顧客中心で、数十年にわたりほとんど革新がなかった業界で競争するだけのより良いデータや技術を持った企業にビジネスチャンスがあることを見出しました。Nubank のモバイルアプリの顧客は、クレジットカードのブロックとブロック解除、信用限度の変更、請求書の支払いを行えるほか、すべての購入にリアルタイムでアクセスできます。また、デジタルチャネルを通じて 24 時間 365 日対応のカスタマーサポートと、明快でシンプルなコミュニケーションも提供しています。これは以前はブラジルの銀行業界ではなかったことであり、Nubank のサービスは顧客の非常に高い評価を受けています。最初から、Nubank のリーダーは成長を計画していました。常に変わる規制やビジネスルールを満たすことができ、サイズと複雑さの両方で完全な管理機能とスケールを持つシステムを構築したいと考えました。同社は、Amazon DynamoDBAmazon EC2Amazon S3AWS CloudFormation など多くの AWS のサービスを利用しています。Nubank は、AWS を利用することで、わずか 7 か月でクレジットカード処理プラットフォームを開発し、簡単に機能を追加できるようになりました。詳細については、Nubank のブログを参照してください。

Ravelin (ロンドン)
Ravelin の画像2015 年に創立された Ravelin は、旅行、小売、食物配達、チケット販売、交通を含むさまざまなセクターにおける多くの大手 e コマースおよびオンデマンド企業と連携している不正検出企業です。同社の創設者 (Martin SweeneyLeonard AustinMairtain O’RiadaNicky Lally の各氏) は、オンデマンドのタクシービジネスでの不正問題の解決を試みているときに、この業務を開始しました。その際に、限られた情報で顧客に関する正確な不正予測を行い、ほとんど瞬時に不正を断定する必要がありました。すぐに、これを行うことができるものが市場にはないことがわかり、創設者は Ravelin を立ち上げる必要性に迫られました。Ravelin では、クライアントは手動の確認に必要な時間を減らし、その代わりに顧客へのサービスに集中することができます。同社の機械学習モデルは、API を介して送信される関連の顧客行動および支払いデータに基づいて、正しい行動と悪意のある行動を予測するよう構築されています。悪意のある行動の発見は Ravelin による不正防止に役立ちます。また、同様に重要なのは、正しいパターンの発見により、善良な顧客のブロックが減ることです。Ravelin は、クライアントのビジネスの運用状況に合わせた速度とスケールでの驚くべき正確性により、核となる技術として機械学習を選択しました。Ravelin は AWS のサービスのスイートを使って、機械学習アルゴリズムによる不正の検出に役立てています。同社のクライアントは世界中に存在しており、ピークのトラフィック時間は予測不可能であるため、Amazon EC2 インフラストラクチャを 1 日に複数回スケールしています。これにより、トラフィックの増加に対応しながら、サーバーのコストを最小化しています。また、Ravelin は Amazon RDSAmazon DynamoDBAmazon ElastiCacheAmazon Elasticsearch Service などのサービスも使用します。これらのサービスの利用により、Ravelin チームは不正検出ソフトウェアの構築に集中する時間をより多く得ることができます。不正防止の最新情報については、ぜひ Ravelin のブログをご覧ください

-Tina Barr

AWS IPv6 の更新 – 15 のリージョンおよび複数の AWS のサービスにまたがるグローバルサポート

過去数年間に、IPv6 のサポートを AWS の多くの異なる部分に追加してきました。最初は Elastic Load BalancingAWS IoTAWS Direct ConnectAmazon Route 53Amazon CloudFrontAWS WAF、および S3 Transfer Acceleration から開始し、最終的には先月発表した Virtual Private Cloud の EC2 インスタンスに対する IPv6 のサポート (当初は US East (Ohio) リージョンで利用開始) にまで拡大されました。本日は、VPC の EC2 インスタンスに対する IPv6 のサポートが、合計 15 のリージョンで利用でき、これらのリージョンのうち 9 つで、IPv6 に対する Application Load Balancer のサポートが利用できるようになったことをお知らせします。IPv6 アドレスを使用できるアプリケーションを構築およびデプロイして、サーバー、オブジェクトストレージ、ロードバランサー、およびコンテンツ配信サービスと通信できます。Apple および他のベンダーからの IPv6 サポートの最新のガイドラインに従い、モバイルアプリケーションは、AWS と通信するときに IPv6 アドレスを使用できるようになりました。

IPv6 が 15 リージョンで利用可能に
新しい VPC および既存の VPC の EC2 インスタンスに対する IPv6 のサポートが、US East (Northern Virginia)US East (Ohio)US West (Northern California)US West (Oregon)South America (Brazil)Canada (Central)Europe (Ireland)Europe (Frankfurt)Europe (London)Asia Pacific (Tokyo)Asia Pacific (Singapore)Asia Pacific (Seoul)Asia Pacific (Sydney)Asia Pacific (Mumbai)、および AWS GovCloud (US) リージョンで利用可能になり、今すぐ使用を開始できます。新しい VPC を作成するときに、AWS Management Console から IPv6 を有効にできます。

Application Load Balancer
US East (Northern Virginia)US West (Northern California)US West (Oregon)South America (Brazil)Europe (Ireland)Asia Pacific (Tokyo)Asia Pacific (Singapore)Asia Pacific (Sydney)、および AWS GovCloud (US) リージョンの Application Load Balancer は、デュアルスタックモードで IPv6 をサポートし、IPv4 または IPv6 経由でアクセス可能になりました (その他のリージョンのサポートは数週間以内に追加する予定です)。ALB を設定するときに dualstack オプションを有効にし、セキュリティグループで要件に応じて IPv6 トラフィックを許可または拒否するようにします。dualstack オプションの選択方法は次のとおりです。

このオプションを有効にするには、 set-ip-address-type コマンドを実行するか、 SetIpAddressType 関数を呼び出します。この新機能の詳細については、ロードバランサーのアドレスタイプに関するドキュメントをご覧ください。

IPv6 のまとめ
VPC の EC2 インスタンスに対する IPv6 のサポート開始までに行われた IPv6 のリリースは、CloudFront、WAF、および S3 Transfer Acceleration です。このリリースにより、個別の CloudFront ディストリビューションに対して IPv6 のサポートを有効にできます。新しく作成したディストリビューションはデフォルトで IPv6 をサポートし、既存のディストリビューションはわずかなクリック操作でアップグレードできます (Route 53 エイリアスレコードを使用している場合、ドメインに AAAA レコードを追加する必要もあります)。IPv6 のサポートを有効にすると、新しいアドレスが CloudFront アクセスログに表示されます。また、このリリースにより、AWS WAF を使用して、IPv4 または IPv6 アドレス経由で到着するリクエストを検査し、S3 Transfer Acceleration 用の新しいデュアルスタックエンドポイントを使用できます。Route 53 – このリリースでは、IPv6 経由の DNS クエリのサポートが追加されました (必要な AAAA レコードのサポートは既に提供されています)。それ以降のリリースで IPv6 エンドポイントのヘルスチェックのサポートが追加され、エンドポイントの状態をモニタリングし、DNS フェイルオーバーを準備できます。IoT – この製品のリリースには、デバイスと AWS IoT 間のメッセージ交換に対する IPv6 のサポートが含まれます。S3 – このリリースでは、デュアルスタックのエンドポイント経由で S3 バケットへのアクセスのサポートが追加されました。Elastic Load Balancing – このリリースにより、Elastic Load Balancer 用のパブリック環境でルーティング可能な IPv6 アドレスが追加されました。Direct Connect – パブリックおよびプライベート VIF (仮想インターフェイス) で single および dualstack 設定をサポートします。

Jeff;