Amazon Web Services ブログ

みなさん、こんにちは！ソリューションアーキテクトの下佐粉です。 この形式で週刊AWSを再開して4ヶ月ぐらい経ちましたが、毎回、記事を書く時間よりも、どのアップデートを紹介するのか選択するのに時間が掛かっている気がします。 それでは、先週の主なアップデートについて振り返っていきましょう。

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30年以上の開発作業の成果である PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。Oracle などの商用データベースから移行する場合、PostgreSQL はオープンソースデータベースの主要な選択肢と見なされています。 AWS は、PostgreSQL データベースのデプロイを、コスト効率の良い方法でクラウドに簡単にセットアップ、管理、およびスケールできるサービスを提供しています。これらのサービスは、Amazon RDS for PostgreSQL および PostgreSQL と互換性のある Amazon Aurora です。 データベースのパフォーマンスは、アプリケーションレベルの多くの要因、および CPU やメモリなどのハードウェアに依存しています。この記事では、主要なパフォーマンス要因の 1 つであるクエリパフォーマンスを取り扱います。クエリの遅延は、ほとんどの環境で一般的に見られる問題です。この記事では以下について説明します。 ネイティブデータベースツールを使用して、どのクエリが遅いかを見つける方法。 Amazon RDS Performance Insights を使用してパフォーマンスの問題を見つける方法。 遅いクエリを修正する方法。 RDS および Amazon Aurora PostgreSQL 環境を管理する開発者と DBA にとって、遅いクエリを特定し、パフォーマンスを向上させるためのチューニングは重要なタスクです。 PostgreSQL には、人気のある pgBadger など、遅いクエリを識別するためのツールが多数用意されています。pgBadger は、PostgreSQL ログファイルからの完全なレポートを使用して速度を上げるために構築された PostgreSQL ログアナライザーです。これは、他の PostgreSQL ログアナライザーよりも優れた小さな Perl スクリプトです。このツールを使用してレポートを生成するには、それに応じてログレベルを設定する必要があります。 次の論理図は、pgBadger の使用方法を示しています。PostgreSQL ログをダウンロードして […]

Amazon Virtual Private Cloud のフローログでは、VPC のネットワークインターフェイスを出入りする IP トラフィックに関する情報を取得することができます。フローログのデータは、Amazon CloudWatch Logs またはAmazon Simple Storage Service (S3) に発行できます。 2015 年にVPC フローログを開始したため、VPC 全体の接続性の問題、侵入の検出、以上の検出、またはコンプライアンスの目的でのアーカイブをトラブルシューティングするなどのさまざまなユースケースにそれを使用してきました。今日まで、VPC フローログは、ソース IP、ソースポート、宛先 IP、宛先ポート、アクション (accept、reject) およびステータスなどの情報を提供します。VPC フローログは一度有効になると、エントリは、次のようになります。 この情報はほとんどのフローを理解するのに十分であった一方で、IP アドレスをインスタンス ID に一致させるため、またはフローの方向性を推測して意味のある結論を得るために、追加の計算と検索が必要でした。 今日、ネットワークフローをより良く理解するために、フローログレコードに含めるために、追加メタデータの可用性を通知しています。豊かなフローログにより、ログデータから意味のある情報を抽出するために必要な計算やルックアップの回数を減らすことで、スクリプトを簡素化し、後処理の必要性を完全に排除することができます。 新しい VPC フローログを作成するときに、既存のフィールドに加えて、次のメタデータを追加することができるようになりました。 vpc-id : ソース Elastic Network Interface (ENI) を含む VPC の ID。 subnet-id : ソース ENI を含むサブネットの ID。 instance-id : ソースインターフェイスに関連付けられたインスタンスの Amazon […]

AWS のサービスやソリューションについて学ぼう – 9 月の AWS オンラインテックトーク この 9 月、AWS のサービスとソリューションについて学んでみませんか。AWS オンラインテックトークは、幅広い技術レベルの幅広いトピックをカバーした、ライブのオンラインプレゼンテーションです。AWS のソリューションアーキテクトやエンジニアが主導するこれらのテックトークでは、テクニカルディープダイブ、ライブデモンストレーション、顧客事例の紹介、AWS エキスパートとの質疑応答などが行われます。今すぐ登録しましょう！ 注意 – すべてのセッションは無料です。また時間は太平洋時間 (PT) です。 今月のテックトーク   コンピューティング 2019 年 9 月 23 日 | 午前 11:00～午後 12:00 (PT) – AWS を使用してハイブリッドなクラウドアーキテクチャを構築 – AWS が提供している幅広いサービスを知り、それぞれのユースケースに最も適したハイブリッドなクラウドアーキテクチャの構築に役立ててください。 2019 年 9 月 26 日 | 午後 1:00～午後 2:00 (PT) – 想像よりも簡単な自己ホスト型の WordPress – Amazon […]

Amazon QuickSight は最近、高度で意味のあるインサイトを求めるために、データに計算を実行できるLevel Aware Aggregations (LAA) を立ち上げました。このブログ記事では、これらの計算をサンプルの売上データセットに適用する例を解説し、皆さんのニーズに合わせてこの機能をすぐに活用していただけるようにします。 Level Aware Aggregations とは? Level Aware Aggregation は、QuickSight の全体的なクエリ評価順序で、希望のレベルで計算できる集計の計算です。QuickSight の評価順序 の詳細については、このリンクを確認してください。現時点まで、QuickSight で可能な唯一の集計タイプは、表示レベル と テーブル計算 の集計タイプでした。 表示レベル集計は、QuickSight ビジュアルのフィールド ウェルに存在するディメンションとメトリックによって定義される集計です。. テーブル計算は、ビジュアルの表示レベルの集計値のウィンドウ化/ロールアップによって計算されます。したがって、定義では、これらは表示レベルの集計が計算された後に計算されます。 Level Aware Aggregations で QuickSight は現在、表示レベル集計の前に値を修正できるようになりました。詳細については、Level Aware Aggregations のドキュメントを参照してください。 お客様のユースケース 存続期間中の注文による顧客の分布 顧客の質問: 1 つの注文、2 つの注文、3 つの注文などを行った顧客の数は? この場合、最初に各顧客が行った注文の総数を集計し、その出力をビジュアルディメンションとして使用します。これは、LAA なしで計算することは可能ではありません。 LAA を使用したソリューション 1.) 顧客ごとに注文の数を計算します。 計算フィールド名:  NumberOrdersPerCustomer 計算フィールド式: countOver({order_id}, [{Customer Id}], PRE_AGG) これは、顧客ごとの注文数を計算してから、ビジュアルの表示レベルの集計を行います。 2.) ビジュアルを作成します。 […]

Amazon RDS は、クラウド内でのリレーショナルデータベースのセットアップ、運用、およびスケーリングを容易にし、ハードウェアのプロビジョニング、データベースの設定、パッチ適用、およびバックアップなどの時間がかかる管理タスクを自動化しながら、コスト効率に優れ、サイズ変更が可能な容量を提供するため、煩わしい作業を AWS にまかせて、ビジネスロジックとアプリケーション機能に集中することが可能になります。 AWS 責任共有モデルでは、データを保護し、災害に備えて適切なバックアップと復旧を確実にすることがユーザーの責任になります。バックアップは、所定の時点におけるデータセットのスナップショットです。最後の完全なバックアップ後に行われた変更のすべてを復元するための復旧戦略を設計してください。 RDS を使用すると、新しいデータベースインスタンスを作成して、特定の時点にデータベースインスタンスを復元することができます。AWS マネジメントコンソール、AWS CLI、または RDS API を使用してポイントインタイムリカバリを実行できます。 組織がコンソールと AWS CLI へのアクセスをデータベース管理者のみに制限している場合があります。現在、AWS CloudFormation はポイントインタイムリカバリをサポートしないため、その次善策として AWS CloudFormation のカスタムリソースがあります。カスタムリソースでは、スタックを作成、更新 (カスタムリソースを変更した場合)、または削除するたびに AWS CloudFormation が実行するテンプレートに、カスタムプロビジョニングロジックを作成することができます。たとえば、AWS CloudFormation のリソースタイプとして使用できないリソースを含めたい場合は、カスタムリソースを使用してこれらのリソースを含めることができます。そうすることで、引き続き単一のスタック内で関連リソースのすべてを管理することができます。 この記事では、カスタムリソースである AWS Lambda 関数を使用して、バックアップ保持期間内の過去の任意の時間に RDS データベースのポイントインタイムリカバリを行う方法について説明します。 ソリューションの概要 RDS サービスは、データベースインスタンスのすべてのトランザクションログを 5 分ごとに Amazon S3 に保存します。コンソールでは、このプロパティがデータベースインスタンスの最終復元時間として表示されます。復元は、バックアップ保持期間内の任意の時点に行うことができます。 この記事では、以下の手順を実行します。 提供されている AWS CloudFormation テンプレートを使用して Lambda 関数と関連する IAM ロールを作成する。 必要なパラメータを持つ Lambda 関数を呼び出して、指定された時間へのデータベースの復旧を検証するために、もう一つの […]

数万社におよぶ企業がペタバイト規模のデータを Amazon Elastic File System (Amazon EFS) に保存しており、その多くが EFS を使ってコンテナ化したアプリケーションのデータです。Amazon EFS ファイルシステムは、Amazon Elastic Container Service (ECS) と Elastic Kubernetes Service (EKS) の両方で起動したコンテナに接続できます。Amazon EFS はコンテナインフラストラクチャと同様に、データの追加や削除の際に設定が簡単でかつ柔軟なスケーリングが可能な完全マネージド型のサービスであるため、コンテナストレージにうってつけの選択肢です。さらに、ペタバイト級のデータだけでなく、1 秒あたりのギガバイトの総スループットや数千の IOPS にも拡張が可能です。このブログでは、コンテナ化したアプリケーションで EFS を使用するためのベストプラクティスに関する、よくある質問をいくつかご紹介します。 コンテナには共有ストレージが必要ですか? 一般に、共有ファイルストレージは、障害に対する回復力が必要な長期にわたって実行するコンテナや、データを相互に共有する必要があるコンテナに適しています。よく目にする例をいくつか挙げましょう。 WordPress や Drupal などのコンテンツ管理アプリケーションは、パフォーマンスと冗長性を確保するために複数のインスタンスにスケールアウトしたり、複数のインスタンス間でアップロード、プラグイン、テンプレートを共有することで利点を享受します。 JIRA、Artifactory、Git などの開発者ツールでは高可用性を実現するためインスタンス間でデータを共有します。これは、永続性のために複数の AWS アベイラビリティゾーンに保持されているコードとアーティファクトを使って行われます。 MXNet や Tensorflow のような機械学習フレームワークは、ファイルシステムインターフェイスを介してデータにアクセスする必要があります。永続的な共有ストレージを使用すると、複数のユーザーとジョブを同じデータセットで並行して実行できます。 Jupyter や Jupyterhub などの共有ノートブックシステムには、ノートブックやユーザーワークスペース用の耐久性のあるストレージが必要です。共有ストレージを使用すれば、データサイエンティストの間で簡単に共同作業が行うことができます。 コンテナデータを永続化する別のオプションとしては、Amazon Elastic Block Storage (EBS) があります。これは MySQL、あるいは Kafka […]

Amazon SageMaker は、TensorFlow を含む一般的なディープラーニングフレームワークをすべてサポートしています。クラウド内の TensorFlow プロジェクトの 85% 以上が AWS で実行されています。プロジェクトの多くはすでに Amazon SageMaker で実行されています。これは、Amazon SageMaker が TensorFlow モデルのホスティングとトレーニングにもたらす大きな利便性によるものです。これには、Horovod とパラメータサーバーを使用した完全マネージド型の分散トレーニングが含まれます。 お客様は、1 週間以上かかる大規模なデータセットのトレーニングモデルにますます関心を持ってきています。この場合、クラスター内の複数のマシンまたはプロセスにトレーニングを分散することにより、プロセスを高速化できる可能性があります。この記事では、Amazon SageMaker により、トレーニングクラスターを直接管理する費用や困難なしに、TensorFlow を使用して分散トレーニングを迅速にセットアップおよび起動する方法について説明します。 TensorFlow バージョン 1.11 以降では、Amazon SageMaker の事前作成された TensorFlow コンテナを使用できます。Python トレーニングスクリプトを提供し、ハイパーパラメータを指定し、トレーニングハードウェア設定を指定するだけです。Amazon SageMaker は、トレーニングクラスターをスピンアップし、トレーニングが終了したらクラスターを破棄するなど、残りの作業を行います。この機能は「スクリプトモード」と呼ばれます。 スクリプトモードは、すぐに使用できる以下の 2 つの分散トレーニングアプローチを現在サポートしています。 オプション #1: TensorFlow のネイティブパラメータサーバー (TensorFlow バージョン 1.11 以降) オプション #2: Horovod (TensorFlow バージョン 1.12 以降) 次のセクションでは、これらの TensorFlow 分散トレーニングオプションを […]

データ型、クエリモデル、インデックスオプション、スケーリングの期待値、パフォーマンス要件を幅広く考慮した場合、データベースは 1 つのサイズですべての製品に合わせることはできません。こうした理由から AWS データベースは多くの種類があり、それぞれが異なる種類のアプリケーションのニーズを満たすように作られています。 QLDB の紹介 本日は、AWS データベースファミリーの最新メンバーである Amazon QLDB についてお話ししたいと思います。最初に 2018 年の AWS re:Invent で発表され、プレビュー形式で利用可能でしたが、5 つの AWS リージョンにおいて本番形式で利用できるようになりました。 QLDB は台帳データベースとして、​​保存したデータの信頼できるデータソース (レコードのシステム として知られる) を提供するように設計されています。更新、変更、または変更不可のデータにコミットされたすべての変更において完全かつ不変の履歴を保持します。QLDB は履歴データへの PartiQL SQL クエリをサポートし、履歴が正確かつ正当であることを暗号で検証できる API も提供します。これらの機能により、QLDB は銀行や金融、e コマース、輸送や物流、人事や給与、製造、政府機関のアプリケーションや、保存したデータの整合性と履歴を維持する必要のあるその他の多くのユースケースに大変適しています。 重要な QLDB の概念 詳しく見ていく前に、最も重要な QLDB の概念を確認しましょう。 台帳 – QLDB 台帳は QLDB テーブルのセットと、テーブルに対する変更の完全かつ変更不可の履歴を保持するジャーナルで構成されます。台帳には名前があり、タグを付けることができます。 ジャーナル – ジャーナルはブロックのシーケンスで構成され、各ブロックは暗号化されて前のブロックにチェーンされているため、変更を検証できます。一方、ブロックにはテーブルに加えられた実際の変更が含まれ、効率的に取得できるようインデックスが付けられています。この追加専用モデルにより、以前のデータを編集または削除できなくなり、台帳が変更不可となります。QLDB を使用すると、ジャーナルのすべてまたは一部を S3 にエクスポートできます。 テーブル – テーブルは台帳内に存在し、ドキュメント改訂のコレクションが含まれます。テーブルは、ドキュメントフィールドのオプションのインデックスをサポートしています。インデックスは、等式 (=) […]

この記事では、Amazon Elastic Inference を Amazon Elastic Kubernetes Service と共に使用する方法について詳しく説明します。Elastic Inference と EKS を組み合わせると、お好みのコンテナオーケストレーションシステムで低コストでスケーラブルな推論ワークロードを実行できます。 Elastic Inference は、AWS で低コストの推論ワークロードを実行するますます一般的な方法になりつつあります。低コストの GPU を搭載したアクセラレーションを Amazon EC2 および Amazon SageMaker インスタンスに追加して、深層学習推論の実行コストを最大 75% 削減できます。また、Amazon EKS も、AWS でコンテナを実行するスタートアップ企業から大企業まで、あらゆる規模の企業にとって重要性が高まっています。管理された Kubernetes 環境で推論ワークロードを実行したい場合、Elastic Inference と EKS を共に使用すると、高速ながら低コストのコンピューティングリソースでこれらのワークロードを実行することができます。 この記事の例は、Elastic Inference と EKS を併用して、ビデオフレームで物体検出を実行するためのコスト最適化されたスケーラブルなソリューションを提供する方法を示しています。具体的には、以下を行います。 Amazon S3 からビデオを読み取る EKS でポッドを実行する ビデオフレームを前処理する Elastic Inference で動作するように変更された TensorFlow Serving ポッドに物体検出用のフレームを送信する。 このコンピューティング集約型のユースケースは、Elastic Inference […]