Amazon Web Services ブログ

2019 年にリリースされた Amazon RDS および Aurora 機能のまとめ

Amazon Relational Database Service (Amazon RDS) で、クラウド内でのリレーショナルデータベースのセットアップ、運用、およびスケーリングが簡単になります。費用効果が高く、容量のサイズ変更も可能です。同時に、ハードウェアのプロビジョニング、データベースのセットアップ、パッチの適用、バックアップといった時間を費やす管理作業を自動化します。そのため、お客様はアプリケーションの開発に集中でき、アプリケーションが必要とする高速な性能、高可用性、セキュリティ、さらに互換性の実現に取り組むことができます。 セルフマネージドデータベースをマネージドデータベースサービスに移行することは新しいスタンダードで、当社は Amazon RDS に矢継ぎ早に機能を追加し続けています。2019 年は忙しい年でした。そこで、さまざまなデータベースエンジンにかけて導入された機能をまとめてみましょう。 Amazon RDS は、10 年以上前の 2009 年 10 月に初めてリリースされました。 Amazon RDS for MySQL からすべてが始まりました。それ以来、合計 7 つのデータベースエンジンオプションに対応するまでになりました。その 7 つとは、Amazon Aurora MySQL、Amazon Aurora PostgreSQL、PostgreSQL、MySQL、MariaDB、Oracle Database、および Microsoft SQL Server です。 2019 年に、Amazon RDS と Aurora データベースエンジン全体で 100 を超える機能をリリースしました。過去の記事をおさらいしたい方は、2018 年のまとめと 2017 年のまとめをご覧ください。まず、データベースの戦略と運用に最大の影響を与えると考えられる、各データベースエンジンと主要なリリースについて説明します。次に、2019 年にリリースしたすべての機能を便宜上分類して以下に列記します。 新しいインスタンスタイプ、リージョン、バージョン – さまざまなデータベースデプロイオプションを提供 管理性 – […]

Read More

Amazon Redshift の速度とスケーラビリティの向上

2012 年に Amazon Redshift がリリースされて以来、その焦点は常に、可能な限り最高のパフォーマンスを、大規模に、そして可能な限り低コストで提供することでした。世界中のほとんどの組織にとって、データウェアハウスに送信されるデータの量は指数関数的に増加しており、そのデータから洞察を得たいと考えている人の数は日に日に増えています。このため、Amazon Redshift は、増え続けるデータを処理し、洞察に対する需要に応えるために継続的に革新を続けています。 Amazon Redshift は、最も要求の厳しいワークロードに対して、大規模な高速パフォーマンスを提供します。そこにたどり着くのは簡単ではありませんでした。これを実現するには、さまざまな技術的な重点領域にわたって一貫した投資が必要です。この記事では、世界最速のクラウドデータウェアハウスを構築するために何が必要だったかを詳しく説明します。

Read More

オンプレミスの VMware 環境での Amazon RDS マネージド型データベースの使用開始

Amazon RDS on VMware は、数十万の顧客が利用している Amazon RDS テクノロジーを使用して、AWS Relational Database Service (RDS) のマネージド型データベース体験をオンプレミスの VMware 環境に拡張します。 この記事では、VMware 管理者とデータベース管理者が RDS on VMware 環境にデプロイする方法を説明します。オンプレミスの vSphere クラスターを RDS on VMware デプロイ用に準備する方法と、RDS on VMware をクラスターにオンボードする方法について説明します。 RDS on VMware アーキテクチャ RDS on VMware は、VMware vSphere 環境のソフトウェアアプライアンスで RDS コネクタを使用します。RDS コネクタを使用すると、AWS リージョンからの専用仮想プライベートネットワーク (VPN) トンネルを介してオンプレミスのリレーショナル DB インスタンスを管理できます。これにより、Amazon RDS のコントロールプレーンがリージョンの AWS クラウドに留まることができます。 Amazon RDS は、セットアップ中に […]

Read More

EMR 6.0.0 の Docker を使用して、Spark の依存関係の管理を簡素化する

強力なデータ処理エンジンである Apache Spark で、データアナリストやエンジニアリングチームが簡単に API やツールを使ってデータを分析できるようになります。しかし、チームで Pythonや R ライブラリの依存関係を管理するのが難しいことがあります。ジョブを実行する前に必要となる可能性がある依存関係のあるライブラリをすべてインストールし、ライブラリのバージョンの競合に対処するのは、時間がかかり、複雑な作業となります。Amazon EMR 6.0.0 では、Docker Hub および Amazon ECR からの Docker イメージを使用して依存関係をパッケージ化できるようにすることで、これを簡素化しています。このため、クラスター全体でクモの巣のような依存関係を管理する必要がなくなり、個々の Spark ジョブまたはノートブックの依存関係をパッケージ化し、管理できるようになります。 この投稿では、Docker を使って Amazon EMR 6.0.0 および EMR Notebooks でノートブックの依存関係を管理する方法を解説します。EMR 6.0.0 クラスターを起動し、ノートブック固有の Amazon ECR の Docker イメージを EMR Notebooks で使用します。 Docker イメージの作成 まず、Docker イメージを作成します。これには、Python 3 と最新バージョンの numpy Python パッケージを含めます。Dockerfile を使用して Docker イメージを作成します。このファイルは、イメージに含めるパッケージと設定を定義するものです。Amazon EMR 6.0.0 で使用する […]

Read More

アクティブラーニングで Amazon SageMaker ラベリングワークフロー用の独自のモデルを持ち込む

Amazon SageMaker Ground Truth を使うと、正確にラベル付けされた機械学習 (ML) データセットを簡単に低価格で構築することができます。ラベル付けコストを削減するために、SageMaker Ground Truth はアクティブラーニングを使用して、ラベル付けが難しいデータオブジェクト (画像やドキュメントなど) と簡単なものを区別します。難しいデータオブジェクトは人間の労働者に送信して注釈を付け、簡単なデータオブジェクトは自動的に機械学習でラベル付けします (自動化されたラベル付けまたは自動ラベリング)。 SageMaker Ground Truth の自動ラベリング機能は、事前定義された Amazon SageMaker アルゴリズムを使用してデータにラベルを付け、サポートされている SageMaker Ground Truth 組み込みタスクタイプの 1 つを使用してラベリングジョブを作成する場合にのみ使用できます。 このブログ記事を使って、独自のアルゴリズムでアクティブラーニングワークフローを作成し、そのワークフローでトレーニングと推論を実行します。この例は、カスタムラベル付けジョブでアクティブラーニングと自動注釈を実行するための出発点として使用できます。 この記事には 2 つの部分があります。 パート 1 では、Amazon SageMaker 組み込みアルゴリズムの BlazingText を使用してアクティブラーニングワークフローを作成する方法を示します。 パート 2 では、BlazingText アルゴリズムをカスタム ML モデルに置き換えます。 これらのパートで使用するコードを実行およびカスタマイズするには、ノートブックインスタンスの SageMaker Examples セクションにあるノートブック bring_your_own_model_for_sagemaker_labeling_workflows_with_active_learning.ipynb(ノートブック) を使用します。このコードはさらにカスタマイズできます。たとえば、この GitHub リポジトリの src ディレクトリにあるコードを使用して、ランダムな選択とは異なるアクティブラーニングロジックを使用できます。 この記事では、UCI ニュースデータセットを使用したカスタムアクティブラーニングワークフローについて説明します。このデータセットには、ビジネス […]

Read More

詳細: Fargate データプレーン

本日、AWS Fargate の新しいプラットフォームバージョン (1.4) をリリースしました。これには、お客様のための数多くの新しい機能が含まれています。これらの機能の詳細については、こちらのブログ記事をご覧ください。プラットフォームバージョン 1.4 で導入された変更点の 1 つは、Fargate のコンテナ実行エンジンとして、Docker Engine を Containerd に置き換えたことです。  このブログ記事では、お客様のコンテナのワークロードにとってこれが何を意味するか、この変更の背後にある動機、およびこの再設計されたコンテナ実行環境 (Fargate データプレーンとも呼ばれます) の内情について詳しく説明します。 用語集 ブログの本編で使用する用語と概念を確認してみましょう。 コンテナランタイム/実行エンジン: これは、コンテナの作成、起動、停止に使用するソフトウェアの一部で、一般的には「コンテナランタイム」とも呼ばれます。それには、たとえば、Docker Engine、Containerd、CRI-O などがあります。 runC: これは、Open Containers Initiative (OCI) ランタイム仕様に基づいてコンテナを生成および実行するためのツールです。 Containerd: これは、通常 runC を使用して、ホスト上のコンテナのライフサイクルを管理するデーモンです。runC と Containerd がどのように相互に作用するかの詳細については、Michael Crosby のブログ記事をご覧ください。 Docker Engine: Docker が提供するコンテナエンジン。通常、これには、コンテナを実行する必要があるホストにインストールする必要がある Docker デーモンバイナリが含まれます。Docker Engine は、runC の上に構築される Containerd に構築されます。 Containerd への切り替えは、Fargate で実行されているコンテナにとってどのような意味があるのか? 端的に言うと、この切り替えにより、ワークロードに何も影響はありません。 Fargate […]

Read More

AWS Fargate のプラットフォームバージョン 1.4.0 をリリース

AWS Fargate は、コンテナを実行するためのマネージドサービスです。Fargate を使用すると、Amazon Elastic Container Service (ECS) と Amazon Elastic Kubernetes Service (EKS) を使用して、インフラストラクチャの保守、パッチ適用、スケーリング、セキュリティ保護、ライフサイクルなどの未分化の重労働に対処する負担なしに、アプリケーションを起動できます。Amazon EC2 はお客様のハイパーバイザーと物理サーバーを抽象化しますが、AWS Fargate はコンテナランタイムと EC2 インスタンスに対して同じことを行います。コンテナの世界で Fargate が果たす役割について詳しく知りたい場合は、こちらのブログ記事をご覧ください。 Fargate は、お客様がインフラストラクチャについて考える必要がないという意味でインフラストラクチャを非表示にしますが、インフラストラクチャはまだ存在し、AWS が管理しています。今もインフラストラクチャ機能がエンドユーザーに表示されるのは、Fargate プラットフォームバージョンの概念によるものです。詳細については、Fargate のドキュメントをご覧いただくか、Fargate プラットフォームバージョンの入門のブログ記事をご覧ください。 入門のブログ記事では、Fargate プラットフォームバージョンを導入した理由と、たとえば、プラットフォームバージョン 1.4.0 をまだ「LATEST」のものとしてタグ付けしていない実務上の理由について詳しく説明しています。 本日、AWS Fargate のプラットフォームバージョン 1.4.0 をリリースします。 このブログ記事では、今回のリリースで有効にした Fargate 機能の概要と、その中で行った変更の一端をご紹介します。これらの根本的な変更は、必ずしもお客様に表示される新しい機能と直接的な関係があるとは限りませんが、同じくらい重要です。 Fargate プラットフォームバージョン 1.4.0 の新機能 プラットフォームバージョン 1.4.0 では、AWS Fargate の新機能がいくつか導入されています。ブログ記事のこのセクションでその新機能について説明します。 特に明記されていない限り、このブログ記事で説明されている新機能は、ネイティブの Fargate プラットフォームに関連するもので、ECS オーケストレーターで直接利用できます。コンテナの世界で Fargate が果たす役割、特に […]

Read More

Fargate プラットフォームバージョンの入門

AWS Fargate は、コンテナを実行するためのマネージドサービスです。これは AWS のマネージドサービスの 1 つで、ユーザーはその中のインフラストラクチャを気にすることなくコンテナを起動できます。別のブログ記事では、AWS Fargate プラットフォームバージョン 1.4.0 で導入した新機能と変更点について詳しく説明しました。一歩下がって、Fargate プラットフォームのバージョンについてもっと全体的な話をしましょう。 ご存知のように、コンテナとコンテナランタイム (Containerd など) の全体的な目的は、コンテナイメージ (ユーザーが提供するもの) を、そのイメージを起動する予定の (AWS Fargate が提供する) オペレーティングシステムから切り離すことです。ただし、これは明確な分離ではなく、これらの 2 つのレイヤーは抽象化の一部をリークしてしまう可能性があります。 リークする抽象化レイヤーは、この業界では新しい出来事ではありません。これは、下のレイヤーで同じデカップリングの目的を果たすハイパーバイザーと VM ではそれほど問題ではありません。とはいえ、これらの 2 つのレイヤー間のインターフェイスは十分に確立されており、相互にリークする可能性は低くても、一方のレイヤーが他方のレイヤーの変更を認識しなければならない状況がありました。たとえば、標準の EC2 インスタンスから Nitro ベースの EC2 インスタンスへの移行と、これが AMI に及ぼす影響について考えてみてください。たとえば、Nitro ベースのインスタンスタイプを使用するには、ドキュメントに記載されているように、AMI に特定のネットワークドライバーを含める必要があります。 上記のため、AWS Fargate で実行されているコンテナに公開しているインターフェイスをより強力に制御する必要がありました。ここで Fargate プラットフォームのバージョンが登場しました。特定のプラットフォームバージョンを選択してそれに固執することにより、開発者は、基盤となるインフラストラクチャとサポートソフトウェアが変更されないようにし、スタック全体で高い忠実度を維持し、抽象化を変更するリスクを軽減できます。 プラットフォームバージョン 1.3.0 をほぼ 1 年前にリリースして以来、かなりの数の新機能を導入してきました。プラットフォームバージョン 1.4.0 の変更点が機能しなくなるとは思いませんが、それが非常に重要な変更であるため、プラットフォームバージョン 1.3.0 に戻ることができる可能性を残しておく方が、新しいプラットフォームバージョンがユーザーにとってより優れたランウェイとなり、採用するリスクが低くなるだろうと判断しました。 Fargate プラットフォームバージョンの消費の基本 […]

Read More

Amazon Elastic Container Service が Amazon EFS ファイルシステムをサポート開始

Jeff がこのブログで Amazon Elastic Container Service の開始について書いてから 5 年になります。私はその記事を読んで、エキゾチックで珍しいコンテナがどのように聞こえるかについて考えたことを覚えています。わずか 5 年後まで話を進めると、コンテナはほとんどの開発者にとって日常生活の一部になっていることでしょう。しかし、お客様が ECS などのコンテナオーケストレーターをますます採用している一方で、このコンテナ化された世界への移行が難しいアプリケーションの種類もまだあります。 コンテナは本来一時的なものであるため、データの永続化または共有ストレージを必要とするアプリケーションを構築しているお客様は、課題に直面しています。コンテナは動的にスケールインおよびスケールアウトされるため、ローカルデータはコンテナが終了すると失われます。本日、Amazon Elastic File System (EFS) ファイルシステムのサポートを開始することにより、ECS 用に変更しようと思います。ECS および AWS Fargate で実行されている両方のコンテナ Amazon Elastic File System (EFS) を使用できます。 この新機能は、コンテンツ管理システム、内部 DevOps ツール、機械学習フレームワークなどの共有ストレージを必要とするアプリケーションをコンテナ化するのに役立ちます。真新しい一連のワークロードではコンテナがもたらすメリットを享受できるようになり、お客様はデプロイプロセスの高速化、インフラストラクチャー利用の最適化、および回復力のあるシステムの構築を可能にします。 Amazon Elastic File System (EFS) は、フルマネージド、高可用性、スケーラブルな共有ファイルシステムを提供します。これにより、コンピューティングとは別にデータを保存できます。これはリージョンサービスでもあります。サービスは 3 つのアベイラビリティーゾーン内およびアベイラビリティーゾーン間でデータを格納し、高可用性と耐久性を実現します。 これまでは、EC2 インスタンスのクラスターでコンテナを実行している場合、ECS で EFS を機能させることが可能でした。ただし、AWS Fargate をコンテナデータプレーンとして使用する場合、この発表を行う以前は EFS ファイルシステムをマウントできませんでした。Fargate では、お客様が Fargate フリート内のマネージドインスタンスにアクセスすることを許可していないため、EFS をセットアップするためにインスタンスに必要な変更を加えることができません。 EFS […]

Read More

Amazon RDS for SQL Server でリージョン内リードレプリカを使用する

Amazon RDS for SQL Server は、リージョン内のリードレプリカをサポートするようになりました。これにより、読み取りワークロードをプライマリデータベースインスタンスからレプリカにオフロードできます。リードレプリカは内蔵の分散型可用性グループ機能を使用しており、Enterprise Edition でご利用いただけます。分散型可用性グループは、2 つの別個の可用性グループにまたがる可用性グループです。分散型可用性グループのメンバーは、それ自体が可用性グループです。Amazon RDS は、このアーキテクチャに、ドメインに依存しない Windows Server Failover Cluster (WSFC) を使用します。この記事では、リードレプリカのアーキテクチャ、リードレプリカの作成方法、およびそれをモニタリングする方法について説明します。 リードレプリカは、SQL Server 2016 Service Pack 2 Cumulative Update 3 (13.00.5216.0.v1) 以降のマルチ AZ 設定の Enterprise Edition でサポートされています。 リードレプリカのマルチ AZ 設定 リードレプリカのマルチ AZ 設定では、プライマリ DB インスタンスでコミットされたトランザクションは、高可用性を目的として同期的にセカンダリレプリカにレプリケートされ、読み取りのスケールアウトのためにリードレプリカに非同期的に送信されます。リードレプリカには、プライマリ DB インスタンスからのほぼリアルタイムのデータが含まれており、それらを使用して、読み取り専用ワークロードをプライマリ DB インスタンスからオフロードできます。そのワークロードには、たとえば、データ更新のレイテンシーをある程度許容できる分析タイプまたはレポートタイプのクエリがあります。さらに、リードレプリカをプライマリまたはセカンダリ DB インスタンスとは異なるアベイラビリティーゾーンでウォームスタンバイソリューションとして使用でき、ビジネスニーズに基づいてレプリカをシングル AZ インスタンスに昇格できます。Transparent Data Encryption (TDE) または AWS KMS […]

Read More