Amazon Web Services ブログ

AWS のお客様は 10 年以上にわたり、SQL Server などのミッションクリティカルな Windows を実行しています。この投稿では、Amazon EBS ストレージを使用して SQL Server のパフォーマンスを最大化する方法について説明します。 永続ブロックストレージはリレーショナルデータベース管理システム (RDBMS) の重要なコンポーネントであり、重要なデータの速度、セキュリティ、耐久性の最終的な責任を担います。AWS は SQL Server のニーズに合わせて、EBS を通じて、高性能で使いやすいブロックストレージを提供しています。 この投稿は、SQL Server データベースアーキテクト、管理者、および開発者に関連した内容です。AWS プラットフォームでの最適なストレージ構成の概要を説明しています。現在 AWS を使用している、またはオンプレミスのワークロードをクラウドに移行しようとしているのであれば、EBS についてのより詳しい情報と基本的な理解を得ることができます。 Amazon EBS の概要 EBS はすべての AWS リージョンで利用可能な、高性能のブロックストレージサービスです。EBS を使用すると、わずか数回のクリックで SQL Server インスタンスにボリュームを作成し接続が可能です。ホストバスアダプター (HBA)、スイッチ、ネットワーク帯域幅、ディスクキャッシュ、コントローラー、ストレージエリアネットワークなどを構成する必要がなくなります。 EBS ボリュームは専用ストレージネットワークを使用してインスタンスに接続し、高速で信頼性の高いボリュームを柔軟にプロビジョニングするため、SQL Server の重要なワークロードにも対応できます。 EBS ボリュームは伸縮自在です。ワークロードを中断することなく、次のような変更を実行できます。 ボリュームサイズを最大 16 TiB まで増やす。 最大 64,000 IOPS までボリュームパフォーマンスを改善する。 SSD […]

多くの企業における IT 部門では、オンプレミスのワークロードをクラウドに移行することの最大の理由の 1 つがコスト削減となっています。今回の記事では、コスト管理についての実例を、Amazon Aurora PostgreSQL のチューニングに着目しながらご紹介していきます。 ヒストリー 私は最近、当社の自動車向けテレマティクスアプリケーションの、AWS への実装作業を指揮するという機会に恵まれました。少し説明しますと、テレマティクスアプリケーションとは、データ提供者から運転データをストリーミングで受信するものです。このデータは、検証、修正、および正規化されます。そして、処理に合わせた変換が行われた後、専用のスコアリングアルゴリズムを用いて、ドライバーの点数付け計算に使われます。このプロジェクトには、次に示す主要な目的がありました。 高い可用性 (HA) の実現 (99.999%) 。 レスポンスタイプは、数ミリ秒台という高いパフォーマンスの実現。 現状の TCO をその何割かまでに削減する。これには、人的および設備的なリソースの削減も含まれます。 実際の使用量を反映した、従量課金制の支払に移行する。 国や地域を問わず、デプロイと新規顧客の受け入れを容易にする。 規模の拡大と需要変動に適応できる、スケーラビリティと伸縮性の獲得。 コストと HA での目標を達成するため、アプリケーションはサーバーレス/マネージド型のアーキテクチャを用いて、ゼロから再設計と再コーディングが行われました。これにより、保守に必要なリソースの最小化と従量課金制の利用がはかられましたこの再設計は、ほとんどの目的を達成し大きな成功となりましたが、コストだけに問題が残りました。オンプレミスに比べればコスト削減ができたものの、依然として想定した金額の 3 倍の金額になってしまったのです。 概要 他のどの変更作業と同様に、オンプレミスから AWS への移行要素には、次の 3 つが含まれます。 人材 処理 テクノロジー 個人的には、人材の要素がキーになると思います。オンプレミス環境とは違い、AWS でのインフラストラクチャーのコストは、いわゆる埋没費用ではありません。AWS での運用コストは、サービス利用量をベースに変化するからです。この利用量には、サービスの実行/経過時間だけでなく、メモリー、ストレージ、I/O といった、サービス毎に違いがうまれるものの利用も含まれます。AWS での課金手法になじむには、少し時間がかかることもあります。作業の工程の見直しやサービスの自動化は、AWS の環境が提供するメリットを活用するための重要なポイントです。 AWS を利用する上でのコスト削減の取り組みは、次のようなステップにグループ分けされます。 AWS のコストを理解する: まず始めに、請求管理ダッシュボードの使用になれることです。それぞれのサービスが、AWS のコストにどの程度影響しているかを理解します。タスクを優先付けするために、まず上位 3 つの高コスト要件に取り組みます。また最終的には、これらの検証がコスト面での重要性だけでなく、セキュリティーの抜け道を洗い出す目的にも重要となります。 ハウスキーピング: サーバーレスでマネージド型のサービスに移行するからといって、データのクリーニングやアプリケーションの保守のためにオンプレミスで行ったベストプラクティスが完全に不要になるわけではありません。むしろ、そういった作業はより厳格に行う必要が生まれます。 アプリケーションとサービスの低い機能を特定し調整します。 詳細情報 […]

こんにちは、ゲームソリューションアーキテクトの 畑史彦 です。 8月21日に第15回となる Game Tech Night を開催致しました。 Game Tech Night は、オンラインゲーム開発と運用に携わる開発者やインフラエンジニアを対象に、ゲームに特化しか技術情報や関連する AWS サービスの情報をお届けすることを目的としたイベントです。最近では概ね 1,2 ヶ月に1度くらいの頻度で定期開催しています。この第15回では 機械学習 をテーマに AWS のソリューションアーキテクトから２つのセッションを実施しました。  

本投稿は、こちらのフォーラムに投稿された Amazon RDS for PostgreSQL をご利用中のお客様向けのアナウンスメントの参考和訳です。 本投稿は、PostgreSQL コミュニティが2020年2月にバージョン9.4を廃止予定であることに従い、2020年1月15日をもって、Amazon RDS が RDS for PostgreSQL 9.4 のサポートを終了することをお知らせするものです。 Amazon RDSは2015年からPostgreSQLメジャーバージョン9.4をサポートしています。本リリース後、機能性、セキュリティ、信頼性、パフォーマンスの観点で大幅な改善がなされたメジャーバージョンが続々とリリースされています。PostgreSQLコミュニティは、PostgreSQL 9.4のリリース終了時期を2020年2月と発表しています。コミュニティサポートモデルに沿って、AWSは9.4.1, 9.4.4, 9.4.5, 9.4.7, 9.4.9, 9.4.10, 9.4.11, 9.4.12, 9.4.14, 9.4.15, 9.4.17, 9.4.18, 9.4.19, 9.4.20, 9.4.21, 9.4.23 のマイナーバージョンを含む、メジャーバージョン9.4のサポートを終了いたします。Amazon RDS では引き続き、バージョン9.5 以降の PostgreSQLデータベースをサポートいたします。 できるだけ早いタイミングで、Amazon RDS PostgreSQL 9.4 データベースインスタンスをバージョン9.6, 10 もしくは、バージョン11 にアップグレードすることを推奨します。9.5 へアップグレードすることも可能ですが、このバージョンは2021年2月にサポート終了が予定されています。 利用中の PostgreSQL 9.4 のマイナーバージョンと PostGIS 拡張の利用有無に応じて、バージョン10 もしくは、11 に直接アップグレードできる可能性があります(※訳者注: […]

みなさん、こんにちは！ソリューションアーキテクトの下佐粉です。 この形式で週刊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 関数を呼び出して、指定された時間へのデータベースの復旧を検証するために、もう一つの […]