Category: Compute

本投稿は Nathan Taber と Michael Hausenblas による寄稿を翻訳したものです re:Invent 2017で、私たちは Amazon Elastic Container Service for Kubernetes(Amazon EKS) を紹介しました。当時発表した次の tenets(信条) は、現在に至るまで引き続き確かなものであると考えています。

増え続けるデータを処理し、新しいデータソースを取り込むことは、多くの組織にとって大きな課題となっています。  多くの場合、AWS のお客様は接続中のさまざまなデバイスやセンサーからメッセージを受け取っていますが、それらを詳しく分析する前に、効率的に取り込み、処理する必要があります。  結果として、あらゆる種類のデータが行き着くソリューションが Amazon S3 となるのは当然と言えるでしょう。  ただし、データが Amazon S3 に格納される方法によって、ダウンストリームデータ処理の効率とコストに大きな違いが生じる可能性があります。  具体的に言うと、Apache Spark では少数の大きなファイルを処理する場合に比べて、小さいファイルを数多く処理すると、ファイル操作に負担がかかります。  これらのファイルにはそれぞれ、メタデータ情報のオープン、読み込み、クローズの処理に数ミリ秒のオーバーヘッドがあります。これらのファイルを数多くファイル操作すると、このオーバーヘッドのために処理が遅くなります。このブログ投稿では、Amazon Kinesis Data Firehose を使用して、Amazon S3 に配信する多数の小さいメッセージを大きいメッセージにマージする方法を説明しています。  この結果、Spark を実行している Amazon EMR の処理が高速化します。 Amazon Kinesis Data Streams と同様、Kinesis Data Firehose は最大で 1 MB のメッセージサイズを受信できます。  単一のメッセージが 1 MB を超える場合は、ストリームに配置する前に圧縮できます。  ただし量が多い場合、メッセージのファイルサイズが 1 MB 以下だと通常小さすぎます。  正しいファイルサイズというものはありませんが、多くのデータセットでは 1 MB を指定するとファイルの数とファイル操作が多すぎることになるでしょう。 この投稿では、Amazon S3 にある Apache Spark を使用して、圧縮ファイルを読み込む方法についても説明します。この圧縮ファイルには適切なファイル名拡張子がなく、parquet […]

コンタクトセンターではデータが重要です。 スーパーバイザとマネージャは、レポートを使用して、チームのパフォーマンスを確認し、要員配置の計画を立てます。 必要なときに必要なデータを人々に提供することは不可欠です。 このブログ記事では、レポートの生成を有効にしてEメールで自動的にユーザーに送信する方法について説明します。 以下のサービスを使用します。 Amazon S3 AWS Lambda Amazon SES Amazon CloudWatch with Amazon Connect このブログでは、 AWS CloudFormationを使用してデプロイを簡素化する方法についても説明します。 このブログのソリューションでは、 Amazon Connectのネイティブレポート機能を使用してレポートを設定およびスケジュールします。 そのスケジュール設定されたレポートは、Amazon Connectの設定で指定したS3バケットに作成されます。 レポートがS3に作成されると、Lambda関数を起動するイベントが発生します。 Lambda関数はイベントを読み取り、S3からレポートを取得して、指定されたEメールアドレスに送信します。 すべてのアクティビティは追跡目的でCloudWatchに記録されます。 では始めましょう。 このセットアップを完了するには、次のものが必要です。 アクティブなAWSアカウント us-east-1（バージニア北部）またはus-west-2（オレゴン）のいずれかにあるAmazon Connectインスタンス。 Amazon SESはこれらのAmazon Connectリージョンでのみ使用可能であるため、この設定ではこれら2つのリージョンのみがサポートされています。 インスタンスを作成したら、電話番号を取得します。 詳細については、Amazon Connect の使用開始を参照してください。 あなたのアカウントに設定されたAmazon SES。 このソリューションでは、Amazon SESを使用してレポートを指定の受信者にEメールで送信します。 SESを使用してEメールを送信するには、送信元アドレスを確認して、自分が所有者であることを示します。 サンドボックスにいる場合は、 送信先アドレスも確認する必要があります。 あなたは、Eメールアドレスまたはドメイン全体を確認することができます。 検証プロセスについては、Amazon SES のIDの検証を参照してください。 アカウントをサンドボックスから削除する方法については、Amazon SES サンドボックスの外への移動を参照してください。 このCloudFormationテンプレートを実行するための適切なIAM権限。 これには、IAMロールとLambda関数を作成する権限が含まれます。 […]

多くのお客様が、その開発環境で Apache Spark および Apache Hive のクエリなどのビッグデータワークロードを実行するために Amazon EMR を利用しておられます。データアナリストとデータサイエンティストは、分析 EMR クラスターとして知られるこれらのタイプのクラスターを頻繁に使用しますが、ユーザーは、作業終了後にクラスターを終了し忘れることがしばしばあります。これはクラスターのアイドル実行につながり、不必要なコストが生じることになります。 このオーバーヘッドを避けるため、EMR クラスターのアイドル状態を追跡し、アイドル状態で長時間にわたって実行される場合にクラスターを終了する必要があります。YARN ジョブが実行されているかどうかをチェックすることによってクラスターのアイドル状態を判断する Amazon EMR ネイティブの IsIdle Amazon CloudWatch メトリックがありますが、クラスターがアイドル状態かどうかを判断するためにも、接続されている SSH ユーザー、または実行中の Presto ジョブなどの追加のメトリクスを検討するべきです。また、Apache Zeppelin で Spark ジョブを実行する場合、ジョブの実行が終了した後でも、IsIdle メトリックが長時間アクティブ (1) 状態のままとなります。このような場合、IsIdle メトリックはクラスターの非アクティブ状態を判断するには適切ではありません。 このブログ記事では、このオーバーヘッドコストを削減するソリューションを提案します。このため、EMR クラスターのマスターノードにインストールされるバッシュスクリプトを実装しました。このスクリプトは 5 分ごとに実行されるようにスケジュールします。スクリプトはクラスターを監視し、5 分ごとにカスタムメトリック「EMR-INUSE」 (0 = 非アクティブ、1 = アクティブ) を CloudWatch に送信します。CloudWatch が事前定義されたデータポイントセットの一部に対して 0 (非アクティブ) を受け取ると、CloudWatch がアラームをトリガーし、アラームがクラスターを終了する AWS Lambda 関数を実行します。 […]

本日より最新世代のAmazon EC2 T3、M5、C5、およびR5インスタンスがAWS 大阪ローカルリージョンで利用可能です。 これらのインスタンスには最新世代のIntelプロセッサが含まれ、仮想化のオーバーヘッドを削減しながら、高性能、高可用性、高セキュリティを提供するためAWS Nitro Systemを使用し構築されています。

SAP SAPPHIRE NOW 2019が今週フロリダで開催されます！私のAWSの同僚もたくさん現地にいるでしょう。そして、彼らは皆さんと喜んで会話したいと思っています。今日は、SAPが推進するOLTPとOLAPのエンタープライズワークロードを稼働するのにAWSが最適な環境であることを確かめるために、私たちが実施してきた取り組みについて、いくつかのお客様のサクセスストーリーを共有し、簡潔な最新情報をお知らせします。

今日、データは、IoT センサー、アプリケーションログ、クリックストリームなどのリソースの非構造化データ、トランザクションアプリケーション、リレーショナルデータベース、スプレッドシートの構造化データなど、あらゆる場所から流れています。データはすべてのビジネスにとって非常に重要な部分になりました。そのため、データから迅速にデータを抽出するために、信頼できる唯一の情報源を維持し、データの取り込みから変換、分析まで、パイプライン全体を自動化する必要があります。 データ量、速度、種類が増えるにつれて、データ分析の複雑さに対する懸念が高まっています。この懸念は、データをビジネスユーザーが使用できる状態にするために必要な手順の数と複雑さから生じています。多くの場合、データエンジニアリングチームは、パイプラインの構築と、その抽出、変換、ロード (ETL) の最適化に時間を費やしています。プロセス全体を自動化することで、価値実現までの時間と運用コストを削減できます。この記事では、完全に自動化されたデータカタログと ETL パイプラインを作成してデータを変換する方法について説明します。 アーキテクチャ この記事では、以下のアーキテクチャを構築して自動化する方法を学びます。 プライマリデータストアとして Amazon Simple Storage Service (Amazon S3) を使用して、サーバーレスデータレイクを構築します。Amazon S3 のスケーラビリティと高可用性を考えると、データの信頼できる唯一の情報源として最適です。 Amazon S3 にデータを取り込み、保存するためにさまざまな手法を使用できます。たとえば、ストリーミングデータを取り込むために Amazon Kinesis Data Firehose を使用できます。既存のデータベースからリレーショナルデータを取得するために AWS Database Migration Service (AWS DMS) を使用できます。また、AWS DataSync を使用して、オンプレミスのネットワークファイルシステム (NFS) からファイルを取り込むこともできます。 取り込まれたデータは Amazon S3 バケットに入り、これを raw ゾーンと呼びます。そのデータを利用できるようにするには、そのスキーマを AWS Glue のデータカタログに登録する必要があります。これを行うには、Amazon S3 トリガーによって呼び出される AWS Lambda 関数を使用して、データをカタログ化する AWS Glue クローラを起動します。クローラによるテーブル定義の作成が完了したら、Amazon […]

2019年3月27日 実施のセミナーのレポート 3部編の Vol.3 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない！Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [本記事]     Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方 [資料はこちら] クラスメソッド株式会社 和田祐介氏

先日 (2019/4/17) 開催しました AWS Black Belt Online Seminar「Amazon VPC Advanced」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20190417 AWS Black Belt Online Seminar Amazon VPC Advanced AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. Transit Gatewayが使えるようになった今、Virtual Gatewayを用いたVPN・DXを敢えて採用するようなケース・利点はあるものでしょうか A. VPC間で通信しない、従来通りのユースケースでは引き続き有効です。Transit Gatewayは機能が多い代わりに通常のVPN/DXとVGWを使うものよりコストがかかりますので、比較検討することが重要になります。https://aws.amazon.com/jp/transit-gateway/pricing/ Q. VPC Sharing にはAWS Organizationsが必要とのことなのですが、一括請求機能の利用だけで要件を満たすのでしょうか？ A. いいえ。一括請求機能では要件を満たしません。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-sharing.html#vpc-share-prerequisites より — 共有 VPC の前提条件 組織のマスターアカウントで、リソース共有を有効にしておく必要があります。リソース共有の有効化の詳細については、AWS RAM User Guide の「AWS Organizations での共有の有効化」を参照してください。 — Q. P.39 TransitGatewayのVPC-CIDRとProduction, TestingといったVPC-CIDRは、従来のVPC運用と同じように分けて考える認識であっていますか？TransitGatewayのVPC-CIDRを広めに取って、その中で個々のVPCを定義しない認識であっていますか？ […]

2019年3月27日 実施のセミナーのレポート 3部編の Vol.2 です。他の回は以下のリンクよりアクセスください。 Vol.1 : 手段先行でも悪くはない！Ruby on LambdaではじめるServerless Vol.2 : Ruby on Lambdaで変わる大規模サービスの裏側 [本記事] Vol.3 : Webアプリエンジニアに贈るアプリケーション開発におけるサーバーレス流の考え方     Ruby on Lambdaで変わる大規模サービスの裏側 [資料はこちら] Sansan株式会社 Eight事業部 Engineering Group/エンジニアリングマネージャー 藤井洋太郎氏