Amazon Web Services ブログ

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 が適用される一般的なシナリオは多数存在し、以下のようなものがあります。 データおよび分析イニシアティブの基盤としてのデータレイクの構築 効率的な大規模バッチデータ処理 ストリーミングインジェストとリアルタイムのイベント処理のためのプラットフォームの構築 […]

近年、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 は唸りました。「誰が離れるのかを予測したいんじゃないんです! 顧客離れを防ぎたいんです!」 「顧客離れに最も関連している要因を教えてもらえれば、ターゲットを絞ったインセンティブプログラムを構築できます」とマーケティング部は述べました。 […]

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 […]

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 […]

深層学習プロジェクトの全体的なライフサイクルを管理することには課題が伴います。特に、複数の別々なツールやサービスを使用する場合はそれが顕著です。たとえば、データの前処理、トレーニングと推論用コードのプロトタイピング、フルスケールでのモデルトレーニングとチューニング、モデルのデプロイ、そしてそれらすべてを稼働環境向けにオーケストレーションするためのワークフローの自動化などには、それぞれ異なるツールが使われるでしょう。ツールの入れ替えで手間がかかると、プロジェクトが遅延しコストは増大しがちです。今回のブログ記事では、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 […]

データベースへの一括更新は混乱を招き、ダウンタイム、ビジネスプロセスのパフォーマンスへの影響や、コンピューティングリソースとストレージリソースの過剰プロビジョニングを引き起こす可能性があります。一括更新を実行する場合、迅速に実行でき、ビジネスを中断することなく運営でき、コストを最小限に抑えるプロセスを選択する必要があります。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 テーブルの一括更新には […]

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 拡張機能は、バージョン […]

Amazon Forecast は、機械学習 (ML) により、それまでの機械学習経験を待つことなく、非常に正確な予測を生成できる完全マネージド型サービスです。Forecast は、製品需要の見積もり、在庫計画、労働力計画など、さまざまなユースケースに適用できます。 Forecast では、プロビジョニングするサーバーや手動で構築する機械学習モデルはありません。また、使用した分だけお支払いいただくようになっており、最低料金や前払い料金を求められることはありません。Forecast を使用するために必要なことは、予測対象の履歴データをご提供いただくことだけです。予測に影響を与えると思われる関連データも併せてご提供ください。後者には、価格、行事、天候など、時により変化するデータと、色、ジャンル、リージョンなどカテゴリに関するデータの、両方が含まれます。このサービスでは、お手元のデータに基づいて機械学習モデルを自動的にトレーニングし、デプロイして、予測を取得するためのカスタム API を提供します。 この記事では、データの抽出、変換、および Forecast の使用を自動化して、定期的な在庫の補充を必要とする小売業者のユースケースについて説明します。これを実現するには、AWS Lake Formation を使用して安全なデータレイクを構築し、データを取り込み、AWS Glue ワークフローを使用してデータ変換を調整し、Amazon QuickSight で予測結果を視覚化します。 ユースケースの背景 小売業者は、在庫の補充を繰り返す必要があります。たとえば、通常は e コマースチャネルと実際の店舗チャネルを通じて販売する衣料品小売業者があるとします。倉庫のコストを最小限に抑えながら需要を満たすために、手持ちの在庫の最適なレベルを維持する必要があります。効果的な在庫管理のためのいくつかの共通質問にお答えください。 次の販売サイクルに向けてサプライヤーに再注文する際に最適な在庫数量はどれくらいですか? サプライヤー宛ての注文書に製品 SKU の構成を含めるには、どうすればよいですか? 各小売店で用意する在庫製品の適切な構成と数量を最も効果的に決めるには、どうすればよいですか? Forecast を使用して、これらの質問に答えることができます。ソースシステムからデータを抽出し、変換を適用してデータを Forecast で使用できるように準備を整え、Forecast を使用してロード、トレーニング、予測を行います。 次の図は、Lake Formation、AWS Glue、および Amazon QuickSight を使用した提案ソリューションのエンドツーエンドシステムアーキテクチャを示しています。 Lake Formation を使用して、データレイクのガバナンスとアクセス制御を管理します。さらに、次のリソースを使用します。 Lake Formation のブループリントが売上データをデータレイクに取り込む AWS Lambda および Amazon S3 イベント通知で AWS Glue […]

モバイルアプリケーションを開発するときは、各プロジェクトについて、クラウドを利用した一連の機能を開発する必要があります。たとえば、ほとんどのアプリケーションでは、ユーザー認証または詳細なアプリ内分析が必要となります。アプリケーションはおそらく REST または GraphQL API を呼び出し、オフラインシナリオとデータ同期をサポートすることが求められます。AWS Amplify を使用すると、このような機能をモバイルアプリケーションやウェブアプリケーションに簡単に統合できます。 AWS Amplify は、安全でスケーラブルなモバイルおよびウェブアプリケーションを構築するためのツールとサービスのセットです。これは、クラウドを利用した機能を追加するためのライブラリと UI コンポーネントのオープンソースセット、クラウドバックエンドを作成および管理するためのコマンドラインインタラクティブツールチェーン、およびフルスタックのサーバーレスウェブアプリケーションをデプロイしてホストする AWS のサービスである AWS Amplify Console という 3 つのコンポーネントで構成されています。 本日、モバイルアプリケーション開発者が安全でスケーラブルなクラウドベースのアプリケーションを簡単に構築することをサポートするための Amplify iOS および Amplify Android ライブラリとツールが利用可能になったことをお知らせいたします。 今日まで、クラウドベースのモバイルアプリケーションを開発するときは、ツールと SDK の組み合わせを使用していました。すなわち、AmplifyCLI を使用してバックエンドを作成および管理し、1 つまたは複数の AWS Mobile SDK を使用してバックエンドにアクセスしていました。一般に、AWS Mobile SDK は、AWS のサービスの API の低レベルのラッパーです。API の詳細を理解し、ほとんどの場合、オブジェクトの (デ) シリアライゼーション、エラー処理など、多くの未分化コードを記述する必要があります。 Amplify iOS と Amplify Android はこれを簡素化します。まず、認証、データの保存とアクセス、機械学習の予測などのユースケース向けのネイティブライブラリを提供します。これらのライブラリは、抽象化を使用してプログラムでベストプラクティスを適用できる宣言型インターフェイスを提供します。AWS のサービスではなくユースケースの観点から考えると、抽象化のレベルが高くなり、開発サイクルが速くなり、コード行が少なくなります。次に、ネイティブ IDE ツールチェーンと統合するツールを提供します。すなわち、iOS […]

特別なコンプライアンスまたは障害復旧の要件を満たさなければならないお客様は、Amazon FSx for Windows ファイルサーバー (Amazon FSx) のデータを別の AWS リージョンに複製する機能が必要でした。AWS リージョンと Amazon FSx には複数ティアの復元力が組み込まれていますが、レプリケーションによって、AWS リージョンに壊滅的な損失を及ぼす稀なシナリオでも顧客データを保護できます。たとえば、Amazon FSx インフラストラクチャを米国の東海岸に設置していて、そのデータのコピーを西海岸に配置したい場合を考えてみましょう (図: バージニア北部とオレゴンリージョン)。 背景として、AWS には現在世界中に 24 の AWS リージョンがあります。各 AWS リージョンは、複数のアベイラビリティーゾーン (AZ) で構成されています。各アベイラビリティーゾーンは複数のデータセンターに指定することができ、全面的には数十万のサーバーを指定できます。 このブログでは、AWS DataSync を使用して AWS リージョン間で Amazon FSx for Windows ファイルサーバーデータを複製するためのアーキテクチャを設定する方法について説明します。このプロセスに含まれる手順は、以下のとおりです。 ステップ 1: ソース AWS リージョンで Amazon FSx for Windows ファイルサーバーを設定する ステップ 2: AWS リージョン間の通信を有効にする ステップ 3: […]