Amazon Web Services ブログ

Amazon RDS および Amazon Aurora for PostgreSQL データベースの一般的な管理者の責任

アマゾン ウェブ サービス (AWS) は、完全マネージド型のリレーショナルデータベースサービスとして、Amazon Relational Database Service (RDS) および Amazon Aurora を提供します。コマンドをいくつか使用するだけで、本稼働データベースのインスタンスを AWS で起動して実行することができます。 オンラインデータベースを使用すれば、データベース管理者 (DBA) は多くのメンテナンスタスクや管理タスクから解放されます。ただし、注意すべき重要な責任がいくつかあります。この記事では、PostgreSQL との互換性のあるデータベースを備えた Amazon RDS for PostgreSQL および Aurora で実行するための DBA タスクについて説明します。 DBA として、お客様はさまざまな分野でビジネスに価値を提供するという日々のプレッシャーに直面しています。ミッションクリティカルなデータベースを実行するための適切なプラットフォームを維持することは、ますます困難になってきています。メンテナンスも、課題の多い作業です。 Amazon RDS と Aurora のリリースにより、インストール、構成、モニタリング、セキュリティなどのタスクに費やす時間は大幅に短縮されました。それでも、複数の重要なタスクを実行する必要はあります。そのいくつかは毎日または週に数回実行し、またいくつかは Amazon RDS または Aurora のインストール時 (インスタンスの作成時) にのみ実行するものです。 実行する必要がある管理タスクには、以下が含まれます。 パラメータグループの設定 セキュリティ グループを使用した IP トラフィックの管理 データベースログファイルの監査 メンテナンスおよび管理アクティビティ バックアップおよびリカバリ戦略の計画 ユーザー管理 データベースのモニタリング パラメータグループの設定 オンプレミスの […]

Read More

Fluentd を使用して Amazon EKS Windows ポッドから Amazon CloudWatch Logs にログをストリーミングする

コンテナはオペレーティングシステム仮想化の方法の 1 つで、リソース隔離処理でアプリケーションとその依存関係を実行できるようにするものです。コンテナを使用することで、アプリケーションのコード、設定、依存関係を使いやすいビルディングブロックに簡単にパッケージ化でき、環境の一貫性、運用効率、開発者の生産性を高め、バージョン管理を行うことができます。 Windows コンテナを使うと、前に述べた利点をすべて享受できるだけでなく、Windows Server 2003、2008、2008 R2 などのサポートされていない運用システムで実行しているレガシーアプリ (現在では、環境全体をセキュリティの脅威にさらし、セキュリティルールのコンプライアンスに準拠していない恐れがあります) を移行することも可能です。 AWS でコンテナを実行する場合、2 つの選択肢があります。1 つ目は、サーバーを管理するかどうかです。コンテナ用のサーバーレスコンピューティングが必要な場合は AWS Fargate を選択し、コンピューティング環境のインストール、設定、管理を制御する必要がある場合は Amazon EC2 を選択します。2 つ目は、Amazon Elastic Container Service (ECS) または Amazon Elastic Kubernetes Service (EKS) のどちらかのコンテナオーケストレーターを選択して使用します。コンテナの詳細については、こちらをご参照ください。 同時に、新しいプラットフォームに移行するには、適切な作業に適切なツールが必要です。このブログ投稿では、ログを一元化する方法として、Windows ポッドで作成した IIS ログを Amazon CloudWatch Logs にストリーミングする方法について解説します。 では、これをどのように実現するかをご説明しましょう。 前提条件および仮定: Amazon EKS クラスター (1.14 以降) が実行中である。ステップバイステップの説明。 Amazon EKS Windows ワーカーノードをリリース起動している。ステップバイステップの説明。 Amazon EKS […]

Read More

AWS Storage Gateway に FIPS 140-2 準拠エンドポイントのサポートが追加されました

AWS Storage Gateway がオンプレミスにデプロイされる、または Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon EC2 インスタンスとしてデプロイされる場合、Storage Gateway は、管理およびデータ移動の両方について AWS リージョンでホストされる Storage Gateway Managed Service に通信を返す必要があります。ゲートウェイとサービス間におけるこの通信を可能にするために、AWS Storage Gateway Managed Service は「サービスエンドポイント」とよばれるものをホストします。 これまでは、次の 2 つのオプションを利用することができました。 パブリックエンドポイント – Storage Gateway はインターネット経由でパブリックエンドポイントに接続します。 VPC エンドポイント – Storage Gateway は AWS へのプライベート接続 (AWS Direct Connect または VPN) 経由で Storage Gateway VPC エンドポイントに接続します。 いずれの場合も、Storage […]

Read More

Analytics Lens を使った AWS Well-Architected 環境の構築

AWS でのモダンデータプラットフォームの構築は、あらゆるタイプのデータを収集し、セキュアな中央リポジトリに保存して、専用ツールを使って分析することを可能にします。しかし、開始方法や特定の設計判断の影響に不安が残っているかもしれません。特定のテクノロジーおよびアプリケーション分野に適した助言を提供するニーズに対応するため、AWS は Well-Architected Lenses 2017 という概念を追加しました。AWS は本日、AWS Well-Architected フレームワークのための Analytics Lens を発表します。この記事は、Analytics Lens の目的を紹介し、対象となるトピック、一般的なシナリオ、および含まれるサービスについて説明します。 新しい Analytics Lens は、お客様の分析アプリケーションが AWS のベストプラクティスに従って設計されていることを確実にするための包括的なガイドラインを提供します。その目的は、以下の 5 つの柱に基づいてクラウドアーキテクチャを設計し、評価するための一貫的な方法を提供することです。 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 このツールは、潜在的なリスクを特定し、改善のための提案を行うことによって、AWS でデプロイされた分析ワークロードを評価する上で役立ちます。 一般的な要件に対応するための Analytics Lens の使用 Analytics Lens は、分析アプリケーションの中核を成すデータアーキテクチャと、アプリケーション動作そのものの両方をモデル化します。これらのモデルは、AWS にデプロイされた分析ワークロードの大部分が含まれる以下の 6 つの領域に分類されます。 データの取り込み セキュリティとガバナンス カタログ化と検索 中央ストレージ 処理と分析 ユーザーアクセス 以下の図は、これらの領域と、それらに関連する AWS のサービスを示したものです。 Analytics Lens が適用される一般的なシナリオは多数存在し、以下のようなものがあります。 データおよび分析イニシアティブの基盤としてのデータレイクの構築 効率的な大規模バッチデータ処理 ストリーミングインジェストとリアルタイムのイベント処理のためのプラットフォームの構築 […]

Read More

Amazon Aurora 機械学習を使用して顧客に関する洞察を得る

近年、AWS のお客様は、ますます多様化するデータセットとデータソースで機械学習 (ML) を実行しています。組織データの大部分は Amazon Aurora などのリレーショナルデータベースに保存されているため、このリレーショナルデータを ML モデルのトレーニングに利用できるようにし、ML モデルを使用してデータベースアプリケーションで予測を行えるようにするニーズが一般的にあります。この記事では、Aurora から本番データを簡単に抽出し、Amazon SageMaker で ML モデルをトレーニングし、モデルの推論を本番データベースとアプリケーションに統合する方法を示します。また、一般的な ML ユースケースを拡張して顧客離れを予測し、顧客離れを防止するという実際のビジネス目標を達成する方法も説明します。セッティングに大手電話会社を用います。 勤務する通信会社で、CEO から会議に呼び出されたとします。「当社のサービスを解約する、つまり「顧客離れ」をするお客様が毎年約 15% います! お客様を失うと、新しいお客様を獲得するには高い費用がかかります。これは当社の年次結果に大きな重しになります。  どのお客様が解約する可能性が高いかを予測して、そのお客様にサービスを使い続けてもらえるようなインセンティブを与えることができますか? 機械学習 (ML) を使ってこれに役立てられますか?」 いつまでも続くこの議論を簡潔にまとめます。 ML エンジニアは次のように言いました。「うーん、そうですね。すべての顧客データが Amazon Aurora リレーショナルデータベースに保存されていますね。DBA がこのデータを取得できれば、解約する顧客を予測する ML モデルを構築できます。Amazon SageMaker XGBoost Built In Model を使ってこれを行えます。これは、一般的に回帰、分類、ランク付けの問題に用いられるアルゴリズムです。そしてSageMaker 自動モデルチューニングで、かなり良いモデルが得られるはずです」 DBA は、「もちろん! 本番データベースの一部のダンプを提供できます。AWS は Amazon Aurora から S3 をダウンロードできるようにしているため、簡単に行えます」 CEO は唸りました。「誰が離れるのかを予測したいんじゃないんです! 顧客離れを防ぎたいんです!」 「顧客離れに最も関連している要因を教えてもらえれば、ターゲットを絞ったインセンティブプログラムを構築できます」とマーケティング部は述べました。 […]

Read More

Amazon S3 バッチオペレーションを使用して保存期間を一括管理する方法

Amazon S3 バッチオペレーションが S3 オブジェクトロックをサポートするようになりました。この記事では、これら 2 つの Amazon S3 機能を一緒に使用して、一般的なデータ保護のニーズに対処する方法を紹介します。S3 バッチオペレーションは、何百万ものオブジェクト間でタグセットをコピーしたり更新したりするなどの反復アクションまたは一括アクションを 1 度のリクエストで実行できる機能です。提供するのはオブジェクトのリストのみで、S3 バッチオペレーションは再試行の管理や進行状況の表示など、すべての手動作業を処理します。S3 バッチオペレーションの詳細については、こちらのブログ投稿をご覧ください。 S3 オブジェクトロックを使用すれば、オブジェクトに保存日と訴訟ホールドを適用して、オブジェクトが無期限、あるいは特定の日付が経過するまで削除または上書きされないようにすることができます。S3 オブジェクトロック向け S3 バッチオペレーションのサポートは、ライトワンスリードメニー (WORM) ストレージの規制要件を満たすのに役立ちます。さらに、オブジェクトを変更または削除する際に保護するためのレイヤーを追加するだけです。 ベーシック Amazon S3 オブジェクトロックには、オブジェクトの保持期間を管理する 2 つの方法があります。 保持期間は、オブジェクトがロックされたままの状態になる固定期間を指定します。この期間中、オブジェクトは WORM で保護されており、オブジェクトのバージョンを削除または変更することはできません。S3 オブジェクトロックは、2 つの保存期間モードを提供します。 ガバナンスモードでは、ほとんどのユーザーによって削除されないようにオブジェクトを保護していますが、保存設定を変更したり、必要に応じてオブジェクトを削除したりする権限をユーザーに付与することもできます。 コンプライアンスモードで保護されたオブジェクトのバージョンは、AWS アカウントのルートユーザーを含め、どのユーザーも上書きまたは削除を行うことができません。 訴訟ホールドは、保持期間として同じ保護を行いますが、期限がありません。代わりに、訴訟ホールドは、明示的に削除するまでその場に置かれたままになります。 オブジェクトのバージョンは、保持期間または訴訟ホールドのいずれか、あるいはその両方の組み合わせを設定できます。たとえば、1 年間の保持時間プラス訴訟ホールドが設定されたオブジェクトをもつ場合があります。正確な保存日がわかる場合は保存期間を使用し、要件に合った保存モードを選択します。 S3 オブジェクトロック向け S3 バッチオペレーションのサポートはいつ使用しますか? バケット内の多数のオブジェクトに S3 オブジェクトロック設定を適用、更新、または削除する必要がある場合は、S3 オブジェクトロック向け S3 バッチオペレーションサポートの使用をご検討ください。S3 オブジェクトロックを初めて使用する場合、S3 オブジェクトロック向け S3 バッチオペレーションのサポートを使えば、これらの変更を簡単に行えます。既存の S3 オブジェクトロック要件が変更され、多数のオブジェクトのロックを更新、追加、または削除する必要がある場合にも当てはまります。オブジェクトがバケットに追加されたときに、S3 […]

Read More

Amazon RDS for PostgreSQL クロスリージョンリードレプリカのためのベストプラクティス

Amazon RDS for PostgreSQL のマネージドサービスのひとつにクロスリージョンリードレプリカがあります。クロスリージョンリードレプリカを使用することで、災害対策ソリューションの確保、データベースの読み込みワークロードのスケーリング、およびリージョン間での移行が可能になります。クロスリージョンリードレプリカは、Amazon RDS コンソール、AWS CLI、または create-db-instance-read-replica API を使用して作成できます。クロスリージョンリードレプリカには、追加のデータ転送料金がかかります。 Amazon RDS はクロスリージョンリードレプリカを容易にしますが、最良の経験を実現するために認識しておく必要がある注意点がいくつかあります。この記事では、以下のトピックに関する Amazon RDS for PostgreSQL クロスリージョンレプリケーションのベストプラクティスを説明します。 クロスリージョンリードレプリカの作成の流れ レプリケーション遅延を最小限化する方法 Amazon RDS for PostgreSQL クロスリージョンレプリカの使用中における一般的な問題 クロスリージョンリードレプリカの作成の流れ クロスリージョンリードレプリカは、Amazon RDS for PostgreSQL のバージョン 9.5.2 以降でサポートされます。クロスリージョンレプリカの作成中、システムは以下のステップを実行します。 ソースインスタンスのスナップショットを作成する。 スナップショットをレプリケーション先のリージョンにコピーする。 ソースとクロスリージョンレプリカ間におけるストリーミングレプリケーションスロットを設定する。 ソースからレプリカへのログ先行書き込み (WAL) のストリーミングを開始する。WAL ファイルは PostgreSQL のトランザクションログです。データ変更は、まず WAL ファイルに記録されてから、永続ストレージに書き込まれます。 Amazon RDS for PostgreSQL のクロスリージョンレプリカは、以下の手順に従うことで最も簡単に作成できます。 Amazon RDS コンソールで、Amazon RDS for […]

Read More

Amazon SageMaker での全体的な TensorFlow 2 ワークフローの作成

深層学習プロジェクトの全体的なライフサイクルを管理することには課題が伴います。特に、複数の別々なツールやサービスを使用する場合はそれが顕著です。たとえば、データの前処理、トレーニングと推論用コードのプロトタイピング、フルスケールでのモデルトレーニングとチューニング、モデルのデプロイ、そしてそれらすべてを稼働環境向けにオーケストレーションするためのワークフローの自動化などには、それぞれ異なるツールが使われるでしょう。ツールの入れ替えで手間がかかると、プロジェクトが遅延しコストは増大しがちです。今回のブログ記事では、Amazon SageMaker を使い、深層学習プロジェクトの全体的なライフサイクルを効率的に管理する方法をご紹介します。ここでは、サンプルコードのフレームワークとして TensorFlow 2 を使いますが、解説しているコンセプトは、他のフレームワークにも基本的に適用可能です。 また記事内では、関連したサンプルノートブックを取り上げていますが、これも、1 時間以内に実行が可能なものであり、解説しているすべての機能をお試しいただくことができます。詳細については、GitHub リポジトリをご参照ください。 Amazon SageMaker ワークフローの概要 TensorFlow 2 あるいは他のフレームワークを使用するデータサイエンスプロジェクトでは、データセットの取得、調査、前処理が、必ず作業の出発点となります。Amazon SageMaker ワークフローについて言えば、データの調査は一般的にノートブック内で行われます。こういったノートブックは、通常、就業時間帯のほとんどで実行されるため、比較的小型でさほどパワーがなく、料金も低いインスタンスタイプに適しています。 したがって、データセットが小さめな場合を除けば、ノートブックはフルスケールのデータ処理やモデルトレーニング、そして推論などに最適とは言えません。通常これらのタスクでは、相当量の並列コンピューティングリソースが必要となるため、ノートブックでの実行は現実的とは言えない訳です。一方で、サイズが最適でよりパワーがあり、これらのタスクが迅速に完了できる個別のインスタンスによるクラスターに、Amazon SageMaker のスピンアップ機能を使用すれば、かなり実践的でコスト効率も良くできます。この場合の料金は秒単位で発生し、各インスタンスはジョブの完了時点で Amazon SageMaker により自動的にシャットダウンされます。結果的に、Amazon SageMaker での通常のワークフローでの最も頻度の高い課金は、パワーがあり高価な GPU や高速化されたコンピューティングインスタンスではなく、データ調査やプロトタイピングを行う比較的低料金のノートブックで発生します。 プロトタイピングが完了すれば、自動化されたワークフローにより、作業はノートブックの上位へと移行されます。頑強かつ反復可能な手法でモデルのデプロイを行うワークフロー全体をオーケストレーションするためには、自動化されたパイプラインが不可欠です。そして、Amazon SageMaker では、このソリューションがネイティブに用意されています。この記事内の以降のセクションにおいて、プロジェクトライフサイクルでの各ステージで実装する、Amazon SageMaker のさまざまな機能をご紹介していきます。 Amazon SageMaker Processing によるデータ変換 Amazon SageMaker Processing は、ノートブックから分離されており適切なサイズで管理されたクラスターでの、大規模なデータセットの前処理に役立ちます。Amazon SageMaker Processing では、用意されたたサポートにより、Scikit-learn がすぐに使えます。また、他のコンテナ化されたテクノロジーもサポートしています。たとえば、Amazon SageMaker Processing の中で、機能変換のために一時的な Apache Spark クラスターを起動できます。 Amazon SageMaker Processing で Scikit-learn […]

Read More

Amazon EMR を使用して Amazon DynamoDB の Time to Live (TTL) 属性をバックフィルする

データベースへの一括更新は混乱を招き、ダウンタイム、ビジネスプロセスのパフォーマンスへの影響や、コンピューティングリソースとストレージリソースの過剰プロビジョニングを引き起こす可能性があります。一括更新を実行する場合、迅速に実行でき、ビジネスを中断することなく運営でき、コストを最小限に抑えるプロセスを選択する必要があります。Amazon DynamoDB などの NoSQL データベースを使ってこれを実現する方法を見てみましょう。 DynamoDB は、テーブル内の項目中、どの項目にも存在しない属性を持てる項目を含められる柔軟なスキーマ構造を提供する NoSQL データベースです (リレーショナルデータベースでは、他の行から除外される一方、一部の行にしか存在できない列もあります)。DynamoDB は極端なスケールで実行するように構築されているため、ペタバイトものデータと数兆もの項目を持つテーブルを使用できます。そのため、このようなテーブル全体の変更を行うには、スケーラブルなクライアントが必要です。このようなユースケースでは、通常、Amazon EMR を使用します。DynamoDB は伸縮自在な容量を提供するため、不定期の一括操作に対応できるように、通常の操作の過程で過剰にプロビジョニングする必要はありません。一括操作中にテーブルに容量を追加し、完了したらその容量を削除するだけです。 DynamoDB は Time to Live (TTL) と呼ばれる機能をサポートしています。TTL を使用すると、期限切れの項目を追加コストなしでテーブルから自動的に削除できます。通常、項目を削除すると書き込み容量が消費されるため、TTL を使用すると、特定のユースケースでは大幅なコスト削減を実現できます。たとえば、TTL を使用して、長期間保持するために Amazon Simple Storage Service (Amazon S3) バケットにすでにアーカイブしたセッションデータまたは項目を削除できます。 TTL を使用するには、タイムスタンプ (Unix エポックからの秒数としてエンコード) を含む項目の属性を指定します。この時点で、DynamoDB は項目が期限切れであると見なします。項目の有効期限が切れると、DynamoDB は通常、有効期限から 48 時間以内に項目を削除します。TTL の詳細については、「Time to Live を使用した項目の期限切れ」を参照してください。 DynamoDB テーブルにデータを配置する前に TTL 属性を選択するのが理想ですが、DynamoDB ユーザーは、テーブルにデータを含めた後に TTL を使い始めることがよくあります。アプリケーションを変更してタイムスタンプ付きの属性を新しい項目または更新された項目に追加するのは簡単ですが、古い項目すべての TTL 属性をバックフィルする最良の方法は何でしょうか? 通常、DynamoDB テーブルの一括更新には […]

Read More

論理レプリケーションを使用してオンプレミスまたは Amazon EC2 から Amazon RDS に PostgreSQL を移行する

PostgreSQL は、オープンソースのリレーショナルデータベースの中でも最も人気のある先進的なシステムの 1 つです。30 年以上におよぶ開発作業を経ている PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。PostgreSQL は、Oracle や Microsoft SQL Server などの商用データベースから移行する際に多くの人から選ばれるオープンソースデータベースです。クラウドの観点から、AWS は 2 つのマネージド PostgreSQL オプションを提供しています。それは、Amazon Relational Database Service (RDS) for PostgreSQL と Amazon Aurora for PostgreSQL です。 PostgreSQL データベースをオンプレミスから AWS マネージド PostgreSQL に移行またはアップグレードする場合、または AWS マネージドサービス内の PostgreSQL のメジャーバージョンにアップグレードする場合は、論理レプリケーションを使用して、ネイティブの PostgreSQL 機能を介して実行できます。pglogical 拡張機能は、バージョン 9.6.6 以降の Amazon RDS for PostgreSQL の一部で、コミュニティ PostgreSQL バージョン 9.4 以降で機能します。 pglogical 拡張機能は、バージョン […]

Read More