Amazon Web Services ブログ

この記事は、FactSet のリードソフトウェアエンジニアである Arvind Godbole と AWS プリンシパルソリューションアーキテクトの Tarik Makota によるゲスト投稿です。「FactSet は、世界中の何万人もの投資専門家向けの柔軟でオープンなデータとソフトウェアソリューションを作成し、投資家が重要な決定を下すために使用する金融データと分析に即座にアクセスできるようにします。FactSet では、製品が提供する価値を常に向上するために取り組んでいます」 私たちが検討してきた分野の 1 つは、クライアントの検索結果の関連性です。さまざまなクライアントの使用例と 1 日あたりの検索回数が多いため、匿名化された使用データを保存し、そのデータを分析してカスタムスコアリングアルゴリズムを使用して、結果を高めることができるプラットフォームが必要でした。計算をホストするために Amazon EMR を使用するのは明らかな選択肢でしたが、匿名化されたデータを Amazon EMR が使用できる形式に変える方法について疑問が生じました。そこで私たちは AWS と協力し、Amazon DynamoDB を使用して Amazon EMR で使用するデータを準備することにしました。 この記事では、FactSet が DynamoDB テーブルからデータを取得し、そのデータを Apache Parquet に変換する方法について説明します。Amazon S3 に Parquet ファイルを保存して、Amazon EMR でほぼリアルタイムの分析を可能にします。途中で、データ型変換に関連する課題に直面しました。これらの課題をどのように克服できたかについて説明しようと思います。 ワークフローの概要 ワークフローには次の手順が含まれています。 匿名化されたログデータは DynamoDB テーブルに保存されます。これらのエントリには、ログの生成方法に応じて異なるフィールドがあります。テーブルに項目を作成するたびに、DynamoDB ストリームを使用してレコードを書き出します。ストリームレコードには、DynamoDB テーブルの単一項目からの情報が含まれます。 AWS Lambda 関数は DynamoDB ストリームにフックされ、DynamoDB […]

本投稿は、Principal Solutions Architectである George Maoの寄稿によるものです。   更新 – (2020年6月30日 PDT): MySQLおよびPostgreSQL対応のAmazon RDS Proxyが一般にご利用可能になりました。 更新 – (2020年4月8日 PDT): PostgreSQL 互換の Amazon RDS Proxy (プレビュー)を発表しました。プレビューではバージョン10.11と11.5がサポートされています。 AWSサーバーレスプラットフォームは、デマンドに応じて自動的に拡張するアプリケーションを構築することができます。大量アクセスがある間、 Amazon API Gateway と AWS Lambda は負荷に応じて自動的にスケールします。 多くの場合、開発者は、Lambda関数からリレーショナルデータベースに保存されたデータにアクセスする必要が出てきます。しかし、Lambdaからデータベースへの多すぎるコネクションにより過負荷にならないようにすることは難しい場合があります。リレーショナルデータベースの最大同時接続数は、データベースのサイズによって異なります。 これは、各コネクションがデータベースサーバー上のメモリとCPUリソースを消費するためです。Lambda関数は数万の同時接続数までスケールできるため、それに対応するには、データベースはクエリを実行するだけでなく、コネクションを維持するためにより多くのリソースが必要になります。 スケーリングの詳細については、アーキテクチャブログの投稿「サーバーレスアプリを大規模に設計する方法」も参照してください。 RDSを使用したサーバーレスアーキテクチャ Lambdaは数万の同時リクエストに応じて簡単にスケールできるため、そのような状況において、この設計ではバックエンドのリレーショナルデータベースに高い負荷がかかります。通常は、リレーショナルデータベースは、Lambdaのスケーラビリティに応じた同時接続を受け入れるように設計されていません。 Amazon RDSのデータベースプロキシ 本日(2019年12月3日 PST)、Amazon RDS Proxyのプレビューを発表できることを嬉しく思います。 RDS Proxyは、アプリケーションとRDSデータベースの間の仲介役として機能します。RDS Proxyは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑えます。 データベースへのSQL呼び出しを行うアプリケーションには、RDS Proxyを使用できます。ただし、サーバーレスのコンテキストでは、これによりLambda利用の体験がどのように改善されるかに焦点を当てています。RDS Proxyは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。 Lambda関数は、データベースインスタンスではなくRDS Proxyと対話します。RDS Proxyは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDS Proxyは自動的にスケーリングされるため、データベースインスタンスでコネクション管理に必要なメモリとCPUリソースが少なくなります。また、暖機されたコネクションプールを使用することでパフォーマンス向上にもつながります。RDS Proxyを使用すると、アイドル接続のクリーンアップとコネクションプールの管理を処理するコードが不要になります。Lambda関数コードは、より簡潔でシンプルとなり、保守性が向上します。 Amazon […]

  概要 つい最近まで、ECS クラスター内での EC2 インスタンスの数を、タスクとサービスに合わせてスケーリングさせようとすると、難しい問題の発生することがありました。  ECS クラスターは必ずしも必要なときにスケールアウトするわけではなく、スケールインは注意深く扱わないと可用性に影響を及ぼします。ときには、顧客はこの課題に対応するため、Lambda 関数などのカスタムの手法、カスタムのメトリクス、そして重量挙げにも例えられるような他の手段に訴えましたが、あらゆる状況でうまくいく単一のアプローチはありませんでした。もちろん、タスクを EC2 インスタンスの代わりに Fargate で実行すれば、クラスターのスケーリングの必要性は全くなくなりのですが、すべての顧客がすべてのワークロードで Fargate を採用する用意ができている、または用意ができるわけではありません。 ECS クラスター Auto Scaling (CAS) は、EC2 Auto Scaling グループ (ASG) のスケーリングを管理する、ECS のための新しい機能です。CAS を使えば、ECS が ASG を自動的にスケーリングするように構成できるので、自分のタスクにのみ注意を集中できます。ECS は必要に応じて ASG がスケールインおよびスケールアウトできるようにします。それ以上の介入は必要ありません。CAS は、ECS クラスターとユーザーが使用する ASG の間をリンクする、ECS のキャパシティプロバイダに依存します。それぞれの ASG は 1 つのキャパシティプロバイダと関連付けられ、キャパシティプロバイダはただ 1 つの ASG を持ちますが、1 つの ECS クラスターには多数のキャパシティプロバイダを関連付けることができます。クラスター全体を自動的にスケーリングするために、それぞれのキャパシティプロバイダが、関連している ASG のスケーリングを管理します。 CAS をローンチする際の私たちの目標の 1 […]

2019 年 12 月、Amazon Elastic Kubernetes Service を使用して AWS Fargate で Kubernetes ポッドを実行できることを発表しました。Fargate を使用すると、Kubernetes アプリケーションの EC2 インスタンスを作成または管理する必要がなくなります。ポッドが起動すると、Fargate はそれらを実行するために計算リソースをオンデマンドで自動的に割り当てます。 Fargate は、マイクロサービスの実行とスケーリングに最適です。特に、スパイクが発生し、予測できないトラフィックパターンがある場合に役立ちます。Amazon Elastic Load Balancing Application Load Balancer (ALB) は、Kubernetes クラスターで実行されているポッドなど、複数のターゲット間でのアプリケーションレイヤー (レイヤー 7) で着信トラフィックを負荷分散する人気のある AWS サービスです。マイクロサービスのようなトラフィックを取得するための優れた方法です。 このブログでは、オープンソースの ALB Ingress Controller を使用して、Fargate ポッドへの入力ベースの負荷分散のために EKS クラスターで AWS Application Load Balancer (ALB) をセットアップする方法を示します。ALB Ingress Controller を使用する Kubernetes Ingress の詳細については、こちらの投稿をご覧ください。 開始するには、Amazon […]

昨年 AWS Backup をリリースして以来、毎日 20,000 を超える AWS のお客様がペタバイトのデータを保護しています。AWS Backup は、Amazon Elastic Block Store (EBS) ボリューム、データベース (Amazon Relational Database Service (RDS) または Amazon DynamoDB)、AWS Storage Gateway、Amazon Elastic File System (EFS) のバックアップ管理を簡素化する、フルマネージド型の一元管理バックアップサービスです。 私たちはお客様のご意見を引き続きお待ちしております。その結果、現在、AWS Backup にエンタープライズデータ機能を追加しています。 Amazon Elastic Compute Cloud (EC2) インスタンス全体をバックアップできるようになりました。 バックアップを他の AWS リージョンにコピーできるようになりました。 完全なファイルシステムではなく、Elastic File System ファイルシステムから単一のファイルを復元できるようになりました。 詳細は以下のとおりです。 EC2 インスタンスのバックアップ EC2 インスタンスのバックアップと復元には、インスタンスの個々の EBS ボリュームだけでなく、追加の保護が必要です。インスタンスを復元するには、すべての EBS ボリュームを復元する必要があります。また、インスタンスタイプ、VPC、セキュリティグループ、IAM […]

アプリケーションを構築または移行する際に、多くの場合、複数の計算ノード間でデータを共有する必要があります。 多くのアプリケーションはファイル API を使用し、Amazon Elastic File System (EFS) では AWS でそれらのアプリケーションを簡単に使用できます。他の AWS サービスおよびオンプレミスリソースからアクセスできる、スケーラブルでフルマネージド型の Network File System (NFS) を提供します。 EFS は、中断することなく、オンデマンドでゼロからペタバイトまで拡張します。また、ファイルを追加および削除すると自動的に拡大および縮小を行い、容量をプロビジョニングして管理する必要性を取り除きます。これを使用することにより、3 つのアベイラビリティーゾーン間で強力なファイルシステムの一貫性が得られます。EFS パフォーマンスは、必要なスループットをプロビジョニングするオプションを使用して、保存されているデータの量に応じて拡大します。 昨年、EFS チームは、EFS Infrequent Access (IA) ストレージクラスを導入することでコストの最適化に注力し、ストレージ料金が EFS 標準と比較して最大 92% 低くなりました。一定期間アクセスされていないファイルを EFS IA に移動するようにライフサイクル管理ポリシーを設定することにより、コストをすぐに削減できます。 現在、アクセスの管理、データセットの共有、EFS ファイルシステムの保護を簡素化する 2 つの新機能を導入しています。 NFS クライアントの IAM 認証と承認により、クライアントを識別し、IAM ポリシーを使用してクライアント固有の権限を管理します。 EFS アクセスポイントは、オペレーティングシステムのユーザーとグループの使用を強制し、オプションでファイルシステム内のディレクトリへのアクセスを制限します。 IAM 認証および承認の使用 EFS コンソールで、EFS ファイルシステムを作成または更新するときに、ファイルシステムポリシーを設定できるようになりました。これは、Amazon Simple Storage Service (S3) のバケットポリシーに類似した […]

スマートビルディング、ユーティリティ、製造システム、コネクテッド製品などの環境を運用するソリューションプロバイダーは、マルチテナントに展開されるIoTプラットフォームを用いたB2Bサービスを提供します。ユースケース、種類、場所、およびテナントごとにこれらのリソースを安全に管理するのは難しい場合があります。 モノの階層的なグループを作成することは一般的なパターンですが、マルチテナンシーにうまく対応していません。たとえば、同じテナントが複数の都市にオフィスを借り、他のテナントと一部の建物を共有する場合、階層的なグループを作成してこれをうまく表現することはできません。一方で、同じリソースが異なるテナント（コネクテッドビークル、賃貸オフィススペース、コネクテッドデバイスなど）によって使用される可能性があります。 この投稿では、IoTのマルチテナント展開でAWSタグを使用して、そのような環境でのAWS IoTリソースの管理とセキュリティを改善する方法について説明します。まず、リソースのタグ付けが重要である理由について説明し、次にAWS IoTのタグ付け機能について掘り下げます。そして、架空のマルチテナントスマートビルディング環境でタグを設定し、使用する手順を実行します。

Verizon Media Group によるゲスト投稿です。 Verizon Media Group (VMG) が直面した大きな問題の一つに、必要な時間内にコンピューティング能力をスケールアウトできないことがありました。つまり、ハードウェアの取得に数か月かかることがよくあったのです。ハードウェアをスケーリングおよびアップグレードしてワークロードの変更に対応することは、経済的に実行が難しく、冗長管理ソフトウェアのアップグレードにはかなりのダウンタイムが必要で、多大なリスクを伴いました。 VMG では、Apache Hadoop や Apache Spark などのテクノロジーに依存し、データ処理パイプラインを実行しています。以前は Cloudera Manager でクラスターを管理していましたが、リリースサイクルが遅いことがよくありました。そのため、利用可能なオープンソースリリースの古いバージョンを実行しなければならず、Apache プロジェクトの最新のバグ修正やパフォーマンスの改善を利用することができませんでした。こうした理由から、既存の AWSへの投資と合わせて、分散コンピューティングパイプラインを Amazon EMR に移行することを検討したのです。 Amazon EMR は Apache Hadoop や Apache Spark などのビッグデータフレームワークの実行をシンプル化する、マネージドクラスタープラットフォームです。 この投稿では、データ処理のニーズに対応するためのパイプラインの構築中に発生し、解決した問題について説明します。 弊社について Verizon Media はつまるところ、オンライン広告会社です。今日のほとんどのオンライン広告は、バナー広告またはビデオ広告としても知られるディスプレイ広告を通じて行われます。すべてのインターネット広告は通常、形式に関係なく、さまざまな種類のビーコンを追跡サーバーに送信します。この追跡サーバーは受信したビーコンを 1 つまたは複数のイベントシンクに記録する唯一の責任を持つ、極めてスケーラブルなウェブサーバーをデプロイします。 パイプラインのアーキテクチャ 弊社では主に動画広告を扱っており、複数の地理的な場所にデプロイした NGINX ウェブサーバーを使用しています。これは、ビデオプレーヤーから直接発生するイベントを、リアルタイム処理用には Apache Kafka に、バッチ処理用には Amazon S3 に記録するものです。弊社グループの典型的なデータパイプラインには、このような入力フィードの処理、検証や強化ルーチンの適用、結果データの集計、およびレポート目的の宛先へのレプリケートが含まれます。次の図は、作成した典型的なパイプラインを示しています。 NGINX ビーコンサーバーで、データの取得を開始します。データは 1 分間隔でローカルディスクの gzip […]

  はじめに ログをセキュアな専用の場所に集約することは、SIEM (セキュリティ情報イベント管理) といった極めて重要な操作を効率化します。より多くのお客様がマルチアカウント戦略を導入している中、一元的なログ記録は運用上の優秀性 (オペレーショナルエクセレンス) を推進する主要要素となっています。そのメリットを考慮して、エンタープライズのお客様はしばしば複雑なサードパーティーツールと使って一元的なログ集約ソリューションを構築します。Amazon S3 Same-Region Replication (SRR) の発表に伴い、お客様はログ集約を含めた数多くのユースケースにこの機能を使用できるようになります。S3 SRR は S3 レプリケーションの機能で、同じ AWS リージョン内にあるバケット間でデータを自動的にレプリケートします。SRR は、特定のバケットまたはプレフィックスにアップロードされた新しいオブジェクトをレプリケートするように設定できます。また、SRR は特定のタグが付けられた新しいオブジェクトを、ユーザーが選択するレプリケーション先にレプリケートすることもできます。お客様は、単一のアカウントまたは複数のアカウントによって所有されている異なる S3 バケットからのログを、今後の処理のために一元化された 1 つのバケットに集約するように SRR を使用することも可能です。 このブログ記事では、S3 SRR を使ってマルチアカウントランドスケープでホストされている VPC からの VPC フローログを収集することによって、ログ集約のデモを行っていきます。今回のセットアップでは、このチュートリアル用に 2 つの AWS アカウント (アカウント A とアカウント B) を使用しますが、シングルアカウントシナリオでのデータ集約にも同じ原則が当てはまります。このセットアップでは、VPC フローログを生成するアカウントをアカウント A、集約されたログバケットをホストするアカウントをアカウント B と呼びます。 前提条件 S3 Same-Region Replication をセットアップするためのステップバイステップガイドを掘り下げていく前に、前提条件を確認しましょう。 アカウント A の前提条件 VPC […]

毎年開催される AWS re:Invent ラーニングカンファレンスでは、新製品とプログラムの発売に満ちた刺激的な時間を過ごすことができます。2012 年に行われた最初の re:Invent カンファレンスで、AWS は Amazon Redshift を発表しました。それ以来、何万人ものお客様にクラウドデータウェアハウスとして Amazon Redshift をご使用いただきました。2019 年、AWS はいくつかの重要な発表を行い、数十のセッションを開催しました。この記事では、re:Invent 2019 で Amazon Redshift に起こったことのハイライトをご紹介します。 AWS re:Invent 2019 での Andy Jassy の基調講演 Andy Jassy が AWS の新機能について話す際、新しい Amazon Redshift のノードタイプであるマネージドストレージ付き RA3、新しい 横串検索 (プレビュー) 機能、Export to Data Lake、Amazon Redshift 向けの Advanced Query Accelerator (AQUA) (プレビュー) をローンチします。YouTube で「AWS re:Invent 2019 – […]