Amazon Web Services ブログ

新規 – リージョン間 VPC ピアリング

最新の AWS re:Invent 2 つのローンチに追いつこうとしているところです! 本日は、リージョン間の VPC ピアリングについてお話したいと思います。2014 年初頭以降、同じ AWS リージョンの仮想プライベートクラウド (VPC) 間でピアリング接続を作成することができるようになっています (詳細は、「New VPC Peering for the Amazon Virtual Cloud」を参照してください)。一旦確立されると、ピアリングされた VPC の EC2 インスタンスは、プライベート IP アドレスを使用して、同じネットワーク上にあるかのように、ピアリング接続を介して互いに通信できます。 re:Invent において、ピアリングモデルを拡張し、AWS リージョン全体で機能するようにしました。既存のモデルと同様に、同じ AWS アカウント内または一対のアカウント間でも機能します。私の以前の投稿に記載されているユースケースはすべて、引き続き適用されます。組織全体の VPC に共有リソースを集中させ、複数の部門ごとの VPC とピアリングすることができます。また、コンソーシアム、コングロマリット、または合弁企業のメンバー間でリソースを共有することもできます。 さらに、リージョン間 VPC ピアリングにより、AWS リージョン間に存在する高度な分離を活用しながら、リージョンにまたがる高度に機能的なアプリケーションを構築することができます。たとえば、計算やストレージリソースの地理的な場所を選択して、規制要件やその他の制約を遵守するのに役立てることができます。 ピアリングの詳細 この機能は、現在米国東部(バージニア州北部)、米国東部(オハイオ州) 、米国西部(オレゴン州)、および EU(アイルランド)リージョン、および IPv4 トラフィックでご利用いただけます。これらのリージョン内の任意の 2 つの VPC は、明確な、重複しない CIDR ブロックを有する限り、接続できます。これにより、すべてのプライベート IP アドレスが一意であることが保証され、一対の VPC […]

Read More

プロセッサの投機的実行 – オペレーティングシステムの更新

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、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 & […]

Read More

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

こんにちは。ソリューションアーキテクトの有岡です。2018年2月のAWS Black Belt オンラインセミナーの配信についてご案内をさせて頂きます。 re:invent 2017の振り返りを終え、2018年2月のBlackBeltセミナーでは、ソリューションカットとしてAWS上での位置情報と動画配信ソリューション、Amazonのコンテナサービスをご紹介します。 サービスカットでは、クラウド型仮想デスクトップサービスのAmazon Workspaces、同じくBIツールのAmazon QuickSight、AWS Lambdaをエッジロケーションで活用する方法、エンタープライズのお客様でお使いになるケースの多いAWS Organizationsなど、盛り沢山でお送りします。   2月の開催予定 ソリューションカット 2月6日(火) 12:00~13:00 AWS における位置情報 2月13日(火) 12:00~13:00 動画配信 on AWS 2月20日(火) 12:00~13:00 Amazon Container Services サービスカット 2月7日(水) 18:00~19:00 Amazon Workspaces 2月14日(水) 18:00~19:00 AWS Organizations 2月21日(水) 18:00~19:00 AWS Lambda @ Edge 2月28日(水) 18:00~19:00 Amazon QuickSight お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同、みなさまのご参加をお待ちしております。    

Read More

Amazon Aurora under the hood: Z-order curvesを用いたgeospatial indexの作成

Amazon Auroraのような高性能データベースシステムを設計する場合、一般的に最も幅広いワークロードを大きく改善出来るように取り組みたいと考えるかと思います。しかし時には、ゲームチェンジャーになりえる機会がある場合、特別な用途向けに改善を行うこともあります。 geospatial indexとはなにか、なぜ考慮する必要があるのか? 地理空間分析では、XY(Z)座標に沿った近さ、隣接性、重なりを識別することができます。 そのような分析を実行する必要があるアプリケーションには様々な例があります。タクシーアプリでは、利用可能な最寄りのタクシーを見つけることができます。不動産アプリは、サンフランシスコのPacific Heights地区で販売されている物件を探すことができます。 空間分析は、他にも多くの用途でも役立ちます: マーケティング – 店舗から2マイル以内のすべての見込み顧客をターゲットにプロモーションを行います 資産管理 – 顧客の位置と密度に基づいて影響を最小限に抑えるために修理ユニットを配置します リスク分析 – 顧客の居住地や職場の近くで車の盗難が発生した場合のリスクを見積もります 詐欺検出 – 前回のトランザクションからの距離に基づいて詐欺と考えられる取引の可能性を推定します ロジスティクス計画 – 運行の範囲を最小限にするように、トラブルのチケットを現場の技術者に割り当てます これらのアプリケーションは、高性能な空間データのインデックスから利益を得ることができます。残念なことに、Bツリーのような伝統的なインデックスは、Linlandのために作られたものであり、FlatlandやSpacelandではそうではありません。そのため、高性能な空間インデックスが必要です。 Rツリーとは? 最も一般的に使用される空間インデックスはRツリーです(詳細はこちらの論文を参照してください)。 MySQLとOracleはどちらもR-treeを使用しています。基本的な考え方は、バランスサーチツリーないにバウンダリーレクタングルを保存することです。リーフはデータポイントであり、各内部ノードは、その下のノードのミニマムバウンダリーレクタングルです。したがって、次の例では、長方形Aはリーフノードです。このノードは、矩形NおよびTによって順番に境界が作成されます。 Rツリーの主な問題は、安定していないことです(つまり、決定論的です)。挿入順序が異なると、異なるツリーが生成され、パフォーマンスの特性が大きく異なります。私たちのテストでは、ランダムな挿入順序では、最適な順序で構築されたツリーよりも1桁も性能が劣化したツリーが生成されました。これは、データの挿入順序が予測できず、変更可能なOLTP環境では明らかに問題になります。このような状況では、Rツリーは時間とともに性能が劣化します。1つの回避策は、データを定期的にインデックスを再構築することです。しかし、インデックスの再構築は負荷がかかります。加えて通常この作業は、手作業が必要であり、数時間かかることがあります。また、その期間中の他のトランザクションは遅くなる可能性があります。 そのため、Rツリーは人気がありますが、常に良好なパフォーマンスは得られません。 他にいい方法はあるのか? 私たちはそう考えています!トランザクションと同時実行に最適なデータ構造があります。それはBツリーです。 あらゆる場面で使用され、高いパフォーマンスを発揮するのはデータベースにとって基本です。 しかし、ちょっと待ってください。私はB-treeが多次元データに対してうまく機能しないと言いました。それは本当です。2次元を1次元にマップするトリックがあります。 私たちは、space-filling z-order curves(空間充填zオーダー曲線)を使用して行います。これは、ポイントのz値は、その座標値のバイナリ表現をインターリーブすることによって計算されます。zオーダー曲線は、これらの点をz値の順に横切る線です。たとえば、次の図は、0≤x≤7、0≤y≤7の整数座標の場合のz値を示しています(10進数と2進数の両方を示しています)。 zオーダー曲線上のBツリーの単純な実装では不十分です。なぜこれが当てはまるのかを知るために、以下の例を見てみましょう。緑色の四角形内のすべての点をBツリーで検索すると、クエリー領域外に30個の余分なz値(黄色い三角形の警告標識が付いている物)がスキャンされます。 元のクエリをより少ない偽陽性z値をカバーする小さなクエリに分割することで、この問題を改善します。(これを行うために幾つかの方法を使用していますが、それはこの記事でお伝えする範囲を超えています) それは私たちがポイントするために必要なものすべてを提示します。ポリゴンはどのように空間充填曲線で動作するのでしょうか?ポリゴンが単一点のように見えるまでズームアウトしたとします。どの程度ズームアウトしなければならないかは、ポリゴンの”レベル”によります。各空間オブジェクトは、オブジェクトのレベルとzアドレスの組み合わせとしてBツリーに格納されます。zアドレスがポイントのように見えるまでズームアウトしたので、zアドレスをポイントのように扱うことができます。他のシステムでは、このレベルを手動で指定する必要があります。明らかに、予測不可能で変更可能なデータを扱うOLTPシステムでは動作しません。このレベルはユーザーの設定なしで自動的に設定します。 Auroraのgeospatial indexesは、MySQL 5.7よりもselect-only(1秒当たりの読み込み回数)ワークロードで10倍以上、write-only(1秒当たりの書き込み回数)で20倍以上優れています。具体的には、サイズが1 GB未満のデータセットでSysbenchを使用して、AuroraとAmazon RDS for MySQL 5.7をdb.r3.8xlargeインスタンスを用いて計測しました。select-onlyのテストでは、2,000クライアントとST_EQUALSクエリを使用しました。write-onlyテストでは、4,000のクライアントを使用しました。 ご質問がある場合は、aurora-pm@amazon.comまでご連絡ください。 About the Author Sirish Chandrasekaran is a product […]

Read More

Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL リードレプリカを作成可能になりました

Amazon Aurora PostgreSQL リードレプリカ(2018/1/23現在英語版ドキュメントのみとなっています)を Amazon RDS for PostgreSQL のインスタンスとして作成し、継続的に Amazon Aurora PostgreSQL へレプリケーション出来るようになりました。これにより、実稼働ワークロードを Amazon RDS for PostgreSQL から Amazon Aurora PostgreSQL に移行する際、アプリケーションとユーザーを Amazon Aurora PostgreSQL へ移す準備ができるまで、インスタンスタイプを同期させておくことで、ダウンタイムを最小化させることが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

暗号化されたスナップショットを Amazon Aurora PostgreSQL へ移行可能になりました

Amazon RDS for PostgreSQL の暗号化されたスナップショットから Amazon Aurora PostgreSQL へ移行できるようになりました。これにより、Amazon RDS から Amazon Aurora へ移行中の間も、データ暗号化を維持することが可能です。 Amazon Auroraは、高性能の商用データベースのパフォーマンスや可用性と、オープンソースデータベースのシンプルさや費用対効果を兼ね備えています。スケーラビリティ、耐久性、およびセキュリティの向上とともに、高いクエリ並列度、データサイズが大きい環境下で標準的なPostgreSQLデータベースのパフォーマンスを最大で3倍向上させます。詳細については、Amazon Auroraの製品ページをご覧ください。 翻訳は江川が担当しました。原文はこちらをご覧ください。

Read More

AWS データセンターのセキュアな設計について

AWS は AWS のデータセンターのデジタルなツアーを公開しました。AWS が世界中で運用しているデータセンターをいかにセキュアに保護しているのか初めてお客様にご紹介するものです。このデジタルなツアー内のビデオ、写真および情報は、データセンターの設計、グローバルの統制および AWS のカルチャーがセキュリティの本質であることを解説しています。 このツアーにご参加いただくことで、AWS データセンターのセキュリティストラテジーが、お客様の情報を保護するためにスケーラブルな統制と複数の防御レイヤーによって成り立っていることを理解いただけます。例えば、AWS は潜在的な洪水や地震活動のリスクを慎重に統制しています。 AWS は境界防御レイヤー、保安要員、侵入検知システムおよびその他の電子システムを用いてデータセンターへのアクセスを制限しています。AWS はシステムのバックアップを実施し、定期的に装置やプロセスのテストを行い、継続的にAWSの従業員にトレーニングを行うことで予測不能な事態に備えています。 データセンターのセキュリティを検証するために、年間を通して、外部の監査人が2,600以上もの基準や要求事項に沿ったテストを行っています。そのような独立したテストが、セキュリティ基準が継続的に満たされている、もしくは基準を上回っている事を証明するために役立っていることになります。その結果、AWS は世界中の最も厳しい基準を有する監査機関からお客様のデータ保護に関して信頼を得ています。 データセンターのセキュアな設計の詳細についてはこちらのツアーにご参加ください。 – Chad Woolf, AWS Security Assurance (翻訳:AWS セキュリティ・アシュアランス本部 戸内加奈。原文はTake a Digital Tour of an AWS Data Center to See How AWS Secures Data Centers Around The World)

Read More

Microsoft Azure SQL Database から Amazon Aurora への移行

Oracle や Microsoft SQL Serverなどのライセンスが必要なエンジンから、AWS上で稼働するオープンソースエンジンへ移行する気運がますます高まっています。対象データの移行先として Amazon Aurora が選ばれています。この投稿では AWS Database Migration Service (AWS DMS) を用いた Microsoft Azure SQL database から Amazon Aurora MySQL クラスタへの移行方法を紹介します。 前提条件 この記事では、Azure SQLデータベースが既にインストールされていることを前提としています。移行には、このデータベースの接続情報(DNSエンドポイント、ユーザー名、パスワードなど)が必要です。また、移行作業に使用するユーザには、Azure SQLデータベースのデータにアクセスするための適切な権限が必要です。 記事の目的に合わせ、ターゲット(移行先データベース)として Amazon Aurora クラスタを作成します。 AWS DMSはソース(移行元データベース)およびターゲットとして、様々なデータベースエンジンをサポートしていますが、多くのお客様は独自のストレージエンジンを使用したAmazon Auroraを選択します。このエンジンは、3つのアベイラビリティゾーンに跨る耐久性、自動ポイントインタイムバックアップ、最大15台の低レイテンシ読み取りレプリカを実現します。 ターゲット用の Aurora クラスタを既に作成している場合は、新規に作成する必要はありません。新しい Aurora クラスタを作成する場合は、Amazon Aurora DB クラスタ作成の手順を参照してください。 AWS DMS インフラのセットアップ ここまででソースとターゲットの情報が確認できたので、AWS DMS インフラを設定していきましょう。 AWS DMSは非常に高い柔軟性をもつ為、多くのコンポーネントから構成されています。AWS CloudFormationを使用することで、これらのコンポーネントをまとめて単一の「スタック」にグループ化し、原子性を保った1つのユニットとして何度も再作成することができます。 AWS CloudFormation のコンソールを開いて設定を始めます。 […]

Read More

最新 EC2 Goodies – 起動テンプレートとスプレッドプレイスメント

いくつかの重要な新しい EC2 インスタンスタイプをローンチして、AWS re:Invent で紹介しています。M5、H1、T2 Unlimited および Bare Metal インスタンス、またHibernation や New Pricing Model などの Spot 機能については、すでにお伝えしてきました。Amazon Time Sync Service については、Randall がお伝えしました。今日は、私たちがローンチした 2 つの機能、すなわち、スプレッドプレイスメントグループと起動テンプレートについて説明いたします。どちらの機能も EC2 コンソールと EC2 API で使用でき、「aws」パーティションのすべての AWS リージョンで使用できます。 起動テンプレート 起動テンプレートを使用して、EC2 インスタンスの起動に使用するインスタンス、ネットワーク、セキュリティ、ストレージ、および高度なパラメータを保存できます。また、任意のタグを含めることもできます。各テンプレートには、パラメータのフルコレクションの希望するサブセットを含むことができます。たとえば、タグやネットワーク構成などの一般的な構成パラメータをテンプレートで定義し、その他のパラメータを実際の起動の一部として指定することができます。 テンプレートを使用して、On-Demand およびSpot フォーム内、および EC2 Auto Scaling を介して、または Spot Fleet の一部として起動されたインスタンスにまたがる、一貫性のある起動環境をセットアップできます。これらを使用して、組織全体の標準を実装し、ベストプラクティスを実施することができます。また、基盤となる API を使用せずに、テンプレートを介してインスタンスを起動する機能を IAM ユーザーに提供できます。 テンプレートはバージョン管理されているので、1 つのインスタンスを起動するときに、任意のバージョンを使用できます。テンプレートは、最初から作成したり、以前のバージョンに基づいたり、または実行中のインスタンスからパラメータをコピーすることができます。 コンソールで起動テンプレートを作成する方法は以下のとおりです。 ネットワークインターフェイス、ストレージボリューム、タグ、およびセキュリティグループを追加する方法は以下のとおりです。 高度なパラメータと特殊なパラメータを指定する方法は以下のとおりです。 テンプレートですべてのパラメータを指定する必要はありません。複数のインスタンスまたは起動に共通する値を起動時に入力して、その他のパラメータを追加できます。 Create […]

Read More

Amazon SageMaker BlazingText: 複数の CPU または GPU での Word2Vec の並列化

AWS は、Amazon SageMaker の最新組み込みアルゴリズムとして Amazon SageMaker BlazingText をリリースします。BlazingText は、Word2Vec 埋め込みを生成するための教師なし学習アルゴリズムです。大規模コーパスには単語の密なベクトル表現があります。Word2Vec の最高速実装である BlazingText が、以下を使用する Amazon SageMaker ユーザーにご利用いただけるようになりました。 シングル CPU インスタンス (Mikolov によるオリジナルの C 実装および fastTextなど) 複数の GPU を備えたシングルインスタンス、P2 または P3 マルチ CPU インスタンス (分散 CPU トレーニング) 単一の p3.2xlarge (Volta V100 GPU 1 個) インスタンス上の BlazingText は、単一の c4.2xlarge インスタンス上の fastText よりも 21 倍速く、20% 割安になる場合があります。 複数の CPU ノード全体における分散トレーニングでは、BlazingText は […]

Read More