Category: Compute

この記事は、Ned T. Sahin 博士 (Brain Power LLC およびハーバード大学)、Runpeng Liu (Brain Power LLC および MIT)、Joseph Salisbury 博士 (Brain Power LLC) と Lillian Bu (Brain Power LLC および MIT) によるゲストブログです。 広告からゲーム、そして教材に及ぶコンテンツの作成者は通常、事後アンケートやテスト、またはクリックスルーやバウンスなどのユーザーアクションによってコンテンツが成功したかどうかを判断します。これらの手法では、コンテンツの作成者が測定したいもの、つまりコンテンツの知覚価値が、客観的、遅発的、略式、事後、および/または相対的な代用物になりがちです。このようなメトリクスは、視聴者がその場で示すボディーランゲージに含まれる可能性がある視聴者の経時的な注意、エンゲージメント、そして快楽に関する継続的で意味のあるデータを見逃します。しかし、ボディーランゲージを数値化する、またはしばしば圧倒的な量になるビデオのデータセット内のパターンや重要なジェスチャーを単一のメトリックに要約するための系統的な手法はありません。 私たちは、落ち着きのない動き (fidgeting) や、その他の身体の動作を行動バイオマーカーとして数値的に要約するために、「Fidgetology」と親しみをこめて呼ばれる手法を発明しました。私たちは当初、自閉症および/または ADHD を持つ子供の拡張現実感システムを使用した後での症状の改善における新しい臨床的評価指標として、これらの子供たちの臨床試験ビデオを分析するために Brain Power (www.Brain-Power.com) で Fidgetology を発明しました。このブログ記事では、より一般化されたアーキテクチャと、目的に応じてすぐに試してみることができるサンプルコードをご提供します。これは、例えばあなたのコンテンツを閲覧している人のビデオなどで身体の動作を自動的に分析するために、アマゾンから新しくリリースされた人工知能製品を使用します。この手法は、映画、広告、テレビ番組、ビデオゲーム、政治運動、スピーチ、オンラインコース、または教室での授業など、様々なコンテンツタイプに応用できます。 この手法を使用することで、視聴者のビデオをストリームまたはアップロードして、視聴者の動作のレベルとパターンのわかりやすい数学的プロットとシングルイメージのサマリーを即座に取得することができます。これらの動作は、注意、焦点、エンゲージメント、不安、または快楽などの要因を推定するために役立ちます。また、これらの要因を確認して分離したり、ユニークなユースケースおよび/または個々のユーザーのためにカスタマイズしたりするために、高度な AWS Lambda 関数や機械学習モデルを追加することもお勧めします。 仕組み システムアーキテクチャダイアグラム Kinesis Video Streams インジェスチョン ビデオストリームを作成するクライアントウェブアプリケーションは、ユーザーが 1) 事前に録画されたビデオをアップロードする、および/または 2) ウェブカムフィードを […]

Amazon Redshift は、システムの履歴を STL ログテーブルに記録するデータウェアハウスサービスです。STL ログテーブルは、ログ使用状況とディスクの空き容量に応じて、2 〜 5 日間だけログ履歴を保持し、ディスクスペースを管理します。 Amazon Redshift は、監査データ用に一部の STL テーブルを Amazon S3 に自動ロギングする機能を備えています。含まれるログは、主にデータベースセキュリティとクエリの実行に関係するものです。これらの監査ログの使用については、前回の記事　「Analyze Database Audit Logs for Security and Compliance Using Amazon Redshift Spectrum」　で説明しました。 監査ログに含まれていない STL テーブルのデータからシステムデータを保持する場合は、通常、すべてのシステムテーブルに対してレプリカテーブルを作成する必要があります。次に、各レプリカテーブルに対し、システムテーブルからのデータを定期的にレプリカにロードします。STL テーブルのレプリカテーブルを管理することで、STL テーブルの履歴データに対して診断クエリを実行できます。その後、クエリの実行時間、クエリプラン、およびディスクスピルのパターンから詳細な情報を導き出し、より良いクラスターサイズを決定します。ただし、定期的な間隔で STL テーブルのライブデータでレプリカテーブルを更新するには、Cron や AWS Data Pipeline などのスケジューラが必要です。また、これらのテーブルは 1 つのクラスターに固有であり、クラスターが終了した後はアクセスできません。これは、アドホッククエリ実行が決められた期間だけ続く一時的な Amazon Redshift クラスターに、特に当てはまります。 このブログ記事では、複数の Amazon Redshift クラスターのシステムテーブルを Amazon S3 バケットにエクスポートするソリューションを紹介します。このソリューションはサーバーレスで、5 分ごとの間隔でスケジュールを設定できます。ここで使用する AWS CloudFormation […]

Amazon Elastic File System はファイルベースのストレージへの共有アクセスが必要なクラウドネイティブなアプリケーション向けにファイルシステム選択肢の一つとなるよう設計されました。私たちは2016年中頃に EFS の提供を始めて、以降、”Direct Connect 経由のオンプレミス環境からのアクセス”や”保管データの暗号化”など重要な機能をいくつも追加してきました。また、EFS を提供する AWS リージョンの追加も行ってきており、直近では US West (北カリフォルニア) が追加されました。EFS 自体がそうであったように、これらの機能追加はお客様からのフィードバックにより為されたもので、益々拡大するお客様の声に応えたいという私たちの願望を反映しています。 伝送データの暗号化 今日、EFS をより便利なものにするために伝送データの暗号化サポートを追加しました。既にサポートしている保管データの暗号化と共に使用する場合、多層防御セキュリティ ストラテジーによる格納ファイルの保護が実現されます。 伝送データの暗号化の実装をより簡単にするために、EFS マウント ヘルパーもリリースします。このヘルパー(ソースコードと RPM 形式で提供)は、EFS への TLS トンネルの確立を助けてくれるもので、また ID によるファイルシステムのマウントもできるようにするものです。この 2 つの機能はそれぞれ独立しています。ヘルパーを使用して、伝送データの暗号化をしていなくても ID でファイルシステムをマウントできます。ヘルパーは実際の mount コマンドのデフォルトオプションの推奨セットも提供してくれます。 暗号化のセットアップ Amazon Linux インスタンスに EFS マウントヘルパーをインストールするところから始めます。 $ sudo yum install -y amazon-efs-utils 次に、EFS コンソールを開き、ファイルシステム ID を取得します。 そして、その ID […]

Amazon ECS でサービスディスカバリがサポートされました。これにより、ECS サービスが Amazon Route 53 の予測可能でフレンドリーな DNS 名で自動的に登録することができるようになります。負荷やコンテナの健全状態に対応してサービスがスケールアップまたはダウンすると、Route 53 のホストゾーンは最新の状態が保たれ、他のサービスが各サービスの状態に基づいてコネクションを行う必要がある場所を発見できるようになります。次のアドレスで、架空のソーシャルネットワークアプリでサービスディスカバリのデモを見ることができます。https://servicediscovery.ranman.com/. サービスディスカバリ マイクロサービスや最新のアーキテクチャへの移行の一部には、障害や変化する負荷に迅速に対応できるダイナミックで、オートスケーリングでき、そして堅牢であるサービスを持つことが必要とされます。皆さんのサービスはおそらく、依存したり利用されるサービスが複雑に関連した依存関係のグラフ構造を持っているでしょう。最新のアーキテクチャのベストプラクティスは、これらのサービスが独自に依存関係を指定できるようにして疎結合にすることですが、ダイナミックな環境では各サービスが自力で自身が接続する先を見つける必要があるため、複雑になってしまう場合があります。 consul、etcd、またはzookeeperなどのサービスディスカバリの従来のアプローチは、すべてこの問題をうまく解決しますが、追加のインフラストラクチャをプロビジョンして管理する必要や、コンテナやインスタンス上にエージェントをインストールする必要があります。これまでは、サービスが互いに発見して接続できるように、独自のサービスディスカバリーシステムを構成して実行するか、すべてのサービスをロードバランサに接続する必要がありました。これからは、ECS コンソール、AWS CLI、または ECS API を使用して、コンテナ化したサービスのサービスディスカバリが可能になります。 Amazon Route 53 サービスレジストリとAuto Naming API の紹介 Amazon ECS サービスディスカバリは、Amazon Route 53 サービスレジストリと Auto Naming API とコミュニケーションすることにより動作します。このブログではこれまでそれらについて触れていないため、ここでは簡単にこれらの Route 53 API の動作について概説したいと思います。最初に、一部の用語について説明します。 名前空間 – 名前空間は、トラフィックを流すドメイン名を指定します (例: internal、local、corp)。これは、サービスが互いに発見できる論理的境界と考えることができます。名前空間は、 aws servicediscovery create-private-dns-namespace コマンドの呼び出しまたはECS コンソールで作成することができます。名前空間は、Route 53 のホストゾーンとほぼ同じです。名前空間にはサービスが含まれます。これは次に取り上げる用語です。 サービス – サービスは「auth」、「timeline」、「worker」などの名前空間にある特定のアプリケーションまたはアプリケーションのセットです。サービスはサービスインスタンスを含みます。 […]

いくつかの必須の EC2 リソースに対する長い ID を提供するための以前の仕事のフォローアップとして、当社は移行の期日を 2018 年 7 月に設定して、同じことを残りの EC2 リソースに対しても行っています。ユーザーごと、リージョンごと、タイプごとにオプトインして、コード、正規表現、データベーススキーマおよびデータベースクエリが期待通りに動作することを確認できます。 EC2 リソースのタイプについて ID を認識、処理、または保存するコードがある場合は、注意深く、この投稿をお読みください。知る必要があることは、次のとおりです。 移行期日 – お使いのコードおよびスキーマが新しい、長い ID を処理し、保存できるのは、2018 年 7 月までです。その後、長い ID はすべての新しく作成されたリソースにデフォルトで割り当てられます。既存のリソースの ID は、そのまま残り、機能し続けます。 詳細なリソースタイプ – 長い ID はすべてのタイプの EC2 リソースに対してサポートされ、希望に応じてオプトインすることができます。 できるだけ早く、テストアカウントから始めて、オプトインするようにお勧めします。このことは、コードを徹底的にテストし、コードを本番稼働させるためにプロモーションする前に、必要な変更を行うための時間を与えます。 その他のリージョン – 長い ID は、現在、AWS 中国 (北京) および AWS 中国 (寧夏) リージョンで使用可能です。 AMI のテスト – テストするために使用できる長い ID をもつ AMI を発行しました […]

多くの画像に対してリサイズを行ったり、新しいデザインレイアウトにウォーターマークを付与したり、ブラウザのサポートのためにフォーマットの最適化を行ったことはありませんか？ 画像毎に事前処理を行う必要なく、必要に応じてその場ですぐに画像を自動生成できないかとおもったことはありませんか？ Lambda@Edge はそれらを可能にし、ユーザーの利便性を向上させ、帯域使用量を削減します。

Amazon EMR により、データアナリストやサイエンティストは、Spark、HBase、Presto、Flink などの一般的なフレームワークを実行する任意のサイズのクラスターを数分でデプロイできます。クラスターを起動すると、Amazon EMR は、クラスター用に選択したフレームワークとアプリケーションを使用して、基盤となる Amazon EC2 インスタンスを自動的に設定します。これには、Hue ワークベンチ、Zeppelin ノートブック、Ganglia 監視ダッシュボードやツールなどの定評があるウェブインターフェイスが含まれます。 これらのウェブインターフェイスは EMR マスターノードでホストされており、マスターノードのパブリック DNS 名 (マスターパブリック DNS 値) を使用してアクセスする必要があります。マスターパブリック DNS 値は動的に作成されますが、あまり使いやすくなく覚えにくいです。たとえば、ip-###-###-###-###.us-west-2.compute.internal などです。一般的なワークベンチまたはノートブックインターフェイスに接続するための使いやすい URL がないと、ワークフローに影響を及ぼし、敏捷性を妨げる可能性があります。 一部の顧客は、カスタムブートストラップアクション、ステップ、定期的に新しいクラスタをチェックしてより使いやすい名前を DNS に登録する外部スクリプトを使用して、この課題に取り組んでいます。こうしたアプローチは、データの実務者にさらに負担をかけたり、スクリプトを実行するために追加のリソースを必要としたりします。さらに、一般的には、こうしたスクリプトに関連する遅延時間があります。クラスターが終了した後に DNS レコードをクリーンアップしてもそれほど大きな効果はなく、むしろセキュリティリスクが発生することがあります。 この記事のソリューションは、ウェブインターフェイスに簡単にアクセスできる使いやすいマスターノード名を登録するサーバーレスの自動化されたアプローチを提供します。

ネットワークストレステスト 【日本語訳】日本時間 2018年02月08日09:00 このポリシーは、お客様の Amazon EC2 インスタンスから、他の Amazon EC2 インスタンス、AWS プロパティ/サービス、外部エンドポイントのような他の場所へ、大規模なネットワークテストを直接実施することを計画しているお客様に関係するものです。 これらのテストは、ストレステストや負荷テスト、ゲームデーテストと呼ばれることがあります。このポリシーでは、テストにおいて正当な大規模トラフィックあるいはテストトラフィックを特定の対象アプリケーションに対し送信する行為を「ネットワークストレステスト」とします。エンドポイントとインフラストラクチャは、このトラフィックを処理できる必要があります。 このポリシーは、通常のプロダクションのトラフィックとは関係ありません。ネットワークストレステストは、多くの場合、特定のエンドポイントを対象とし、送信元や対象が集中することを含め、通常とは異なるトラフィックパターンを持ち、持続的に大規模なトラフィックが発生し、予期している上限値を超える可能性があるため、通常のプロダクションとは異なります。ネットワークストレステストにおけるこれらの違いは、外部エンドポイント、他のお客様、AWS サービスに対し意図しない影響を与えうる潜在的なリスクとなります。 パケットや接続のフラッディング、それ以外の大規模なトラフィックで、ターゲットやインフラストラクチャへ意図的に過大な負荷をかけるテストは、ネットワークストレステストではなく、分散型 DoS (DDoS) テストとして扱われます。ボリュームのあるネットワークベースの DDoS シミュレーションは、Amazon EC2 プラットフォームでは明示的に禁止されています。このポリシーは、https://aws.amazon.com/security/penetration-testing の範囲のセキュリティやペネトレーションテストは対象としません。 ほとんどのお客様はこのポリシーには該当しません。通常、ユニットテストのように大規模なワークロードをシミュレートするストレステストでは、ネットワークストレステストに該当するだけのトラフィックは生成されません。このポリシーは、お客様のネットワークストレステストによって、Amazon EC2 インスタンスで以下の基準を満たすトラフィックが生成されたときに適用されます。”持続的に 1分以上の間 1 Gbps（秒間 1億ビット）あるいは 1Gpps（秒間 1億パケット）を超えるトラフィック、悪用目的や悪意があるように見えるトラフィック、テスト対象以外（ルーティングや共有サービスのインフラストラクチャなど）へ潜在的に影響を及ぼしうるトラフィック” などが該当します。 お客様は、対象のエンドポイントへのテストが承認され、その起こりうる規模について理解している必要があります。いくつかの外部エンドポイントや AWS サービスは、ある種のテストシナリオに対して期待する閾値よりも低い性能しか発揮できない可能性があります。 AWS を利用する多くのお客様は通常のプロダクションモードで定期的に 1Gbps もしくは 1Gpps 以上のトラフィックを生成していることを確認しております。これは完全に正常であり、特にネットワークストレステストの目的のために実施されたものではない限り、このポリシーの範囲下ではありません。 このポリシーの基準を満たすネットワークストレステストにはリスクがあります。お客様が悪質であると検知され報告されるリスク、お客様が意図せず悪質となり他の対象に影響を及ぼすリスク、お客様が所有するインスタンスで機能制限を受ける可能性などがあり、この際にはテストだけではなく、プロダクションのワークロードへ影響する可能性があります。 実施するテストがこれらの基準を満たすか、お客様で不明な場合は、このポリシーに従い、AWS 側にテストの評価を依頼する必要があります。お客様の体験や、その他の影響を受ける可能性があるサービスを改善していくため、これらのストレステストを実行する前には、Amazon EC2 ネットワークストレステストを申し込みフォームから申請してください。このフォームは aws-security-simulated-event@amazon.com へメールを送ることで入手できます。 お客様のネットワークストレステストが 外部や他の AWS サービスのような EC2 インスタンス以外から直接実行される場合、フォームからの申請が必要かどうかメールでお問い合わせください。 […]

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注：このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。（訳注：こちらにエディションの違いの詳細があります） この記事のステップを進めていくと、2つのアベイラビリティゾーン（AZ）にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの２つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin（セキュリティ情報）AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化（PV）インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離（信頼できないデータ処理やコードの実行、ユーザのホスト）にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点（およびインスタンスアップグレードパスのドキュメント）の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]