Amazon Web Services ブログ

先日 (2019/11/14) 開催しました AWS Black Belt Online Seminar「 AWS Transit Gateway 」の資料を公開しました。当日、参加者の皆様から頂いた QA の一部についても共有しております。 20191113 AWS Black Belt Online Seminar AWS Transit Gateway from Amazon Web Services Japan   AWS クラウドサービス活用資料集（すべての過去資料が閲覧できます） Q. TGW を使う場合、DXGW も一緒に使う必要がありますか？TGW のみでも利用できるのでしょうか？ A. Direct Connect を使う場合は、DXGW を一緒に使う必要があります。構成については、こちらをご参照ください Q. VPC をアタッチするときに指定するサブネットをアタッチ専用のサブネットとする必要性について、もう少し具体例を挙げて説明していただきたいです。そのサブネットの内部のEC2 インスタンスのルーティングに影響あるとのことでしたが、どのような影響があるのか？などを教えていただきたいです。 A. Transit Gateway (TGW) のアタッチメントがついているサブネットと同一のサブネットに EC2 インスタンスが存在する場合に、その EC2 インスタンスはTGWと同じルーティングテーブルを参照します。 例えば　インライン監査用の […]

たいていの企業と同様であれば、お客様とブランドイメージをよりよく理解したいと考えておられるでしょう。マーケティングキャンペーンの成功と、お客様が関心を持っているトピック、あるいは不満を感じているトピックを追跡したいと考えておられるでしょう。ソーシャルメディアはこの種の情報の豊富な情報源になると期待されており、多くの企業が Twitter などのプラットフォームから情報を収集、集約、分析し始めています。 ただし、ソーシャルメディアでの会話の中心は画像と動画です。ある最近のプロジェクトでは、収集されたすべてのツイートの約 30% に 1 つ以上の画像が含まれていました。こうした画像には、分析なしでは簡単にアクセスできない関連情報が含まれています。 このブログ記事について 完了するまでの時間 1 時間 完了するためのコスト ~ 5 USD (公開時、使用する条件による) 学習レベル 中級 (200) AWS のサービス Amazon Rekognition Amazon Athena Amazon Kinesis Data Firehose Amazon S3 AWS Lambda ソリューションの概要 次の図は、ソリューションコンポーネントと、画像や抽出データがコンポーネントの間をどのように流れるかを示しています。 これらのコンポーネントは、AWS CloudFormation テンプレートを介して利用できます。 Twitter Search API はツイートを収集します。 Amazon Kinesis Data Firehose は、ツイートを送信して、Amazon S3 に保存します。 指定されたバケットフォルダーで S3 オブジェクトが作成されると、Lambda 関数がトリガーされます。 Lambda […]

このシリーズの最初の投稿である RDS および Aurora PostgreSQL ログの操作: パート 1 では、PostgreSQL のログの重要性と、より多くのデータベースアクティビティの詳細情報をキャプチャするためのさまざまなパラメータを調整する方法を記載しています。PostgreSQL ログは、データベースの問題を解決するのに役立つ情報を提供します。この投稿は、PostgreSQL ログにアクセスするためのさまざまな方法に焦点を当てています。 PostgreSQL ログはクラスターの各インスタンスに生成および保存されます。これらのログファイルにアクセスする方法は複数あります。以下のセクションでは、これらの方法をいくつか説明します。 AWS マネジメントコンソールにアクセスする PostgreSQL ログファイルにアクセスするための最も直接的な方法は、AWS Management Console を介して行います。以下の手順を実行します。 Amazon RDSを開きます。 RDS/Aurora インスタンスを選択します。 [ログとイベント] を選択します。 [Logs] で必要なログファイルを選択します。 [View]、[Watch]、または[Download]のいずれかを選択します。 以下のスクリーンショットは、[Logs] セクションのプレビューです。 これは、ログファイルを表示またはダウンロードするための最も基本的な方法です。 CloudWatch Logs にログファイルを発行する RDS および Aurora PostgreSQL は、Amazon CloudWatch Logs へのログの発行をサポートしています。詳細については、RDS ユーザーガイドの「PostgreSQL ログの Amazon CloudWatch Logs への発行」を参照してください。 ログが CloudWatch Logs の場合、アラームを作成し、リアルタイム分析を行うことができます。たとえば、log_statements を […]

PostgreSQL は最も人気のあるオープンソースのリレーショナルデータベースシステムの 1 つです。30 年以上におよぶ開発作業を経ている PostgreSQL は、多数の複雑なデータワークロードを処理できる、信頼性が高く堅牢なデータベースであることが証明されています。AWS は 2 つのマネージド型 PostgreSQL オプションを提供しています。Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL です。デバッグやモニタリングのためのデータベースアクティビティログをどのようにキャプチャするのかという質問が、新規の PostgreSQL ユーザーから多く寄せられます。この記事では、RDS および Aurora PostgreSQL を設定して追加のエンジンログを生成する方法について説明します。記事の第 2 部である RDS および Aurora PostgreSQL ログの操作: パート 2 では、これらのログファイルにアクセスする方法をご紹介します。 PostgreSQL は、データベース管理者 (DBA) に役立つ情報を含むイベントログを生成します。デフォルトでは、SQL クエリエラー、ログイン試行の失敗、デッドロックがデータベースログにキャプチャされます。これらのエラーメッセージはアプリケーションのさまざまな問題の特定に役立ちます。たとえば、レガシーアプリケーションを Oracle から PostgreSQL に変換すると、一部のクエリが PostgreSQL 構文に正しく変換されないことがあります。こうした誤った形式のクエリによってログにエラーメッセージが生成されるため、問題のあるアプリケーションコードを特定するのに役立ちます。 デフォルトのログ記録を使用するだけでなく、PostgreSQL ログ記録パラメータに変更を加えれば、パフォーマンスの低下やセキュリティ監査などの問題を特定、解決するのに役立つ情報を取得できます。このログ記録パラメータを設定すると、接続と切断、スキーマ変更クエリ、すべてのスロークエリとその時間、ロックのため待機中で時間がかかるクエリ、一時的なディスクストレージを消費するクエリ、リソースを消費するバックエンド自動バキュームプロセスなどの情報をキャプチャできます。 このログ情報は、データベース使用中の潜在的なパフォーマンスと監査の問題をトラブルシューティングするのに有用です。この記事では、このログ記録の有効化とその利点について詳しく説明します。 DB パラメータグループ RDS および Aurora […]

クラウドコンピューティングのメリットのひとつは、インフラストラクチャをプログラム的に作成し、必要なくなったら破棄する可能性です。これは、アプリケーションをデプロイする方法を、開発者が根本的に変えることを可能にします。オンプレミスでアプリケーションをデプロイしていた頃、開発者はアプリケーションの新しいバージョンのために既存のインフラストラクチャを再利用しなければなりませんでした。クラウドでは、開発者がアプリケーションの新しいバージョンのために新しいインフラストラクチャを作成し、古いバージョンを破棄する前にしばらく並行して実行させておきます。この手法はブルー/グリーンデプロイメントと呼ばれます。これは、アプリケーションの 2 つのバージョン間のトラフィックを漸進的に切り替え、新しいバージョンでのビジネスメトリクスと運用メトリクスを監視して、問題が発生した場合にはトラフィックを前のバージョンに戻すことを可能にします。 ブルー/グリーンデプロイメントを導入するために、AWS のお客様は 2 つの戦略を導入します。最初の戦略は 2 番目のアプリケーションスタックの作成で構成されており、これには 2 番目のロードバランサーが含まれます。開発者は、DNS などの何らかの加重ルーティング手法を使用して、トラフィックの一部を各スタックに送ります。2 つ目の戦略は、ロードバランサーの背後にあるインフラストラクチャの交換で構成されています。どちらの戦略も、クライアントマシン上の DNS TTL およびのキャッシングに応じてバージョン間でのトラフィックの移動に遅延を生じさせる場合があります。これらは、追加のロードバランサーを実行するための追加コストと、追加のロードバランサーをウォームアップするための遅延の可能性を生じ得ます。 ターゲットグループはロードバランサーに、トラフィックを EC2 インスタンス、固定 IP アドレス、または AWS Lambda 関数などのどこに送るかを指示します。ロードバランサーを作成する時は、1 つ、または複数のリスナーを作成し、1 つのターゲットグループにトラフィックを送るためのリスナールールを設定します。 本日、AWS は Application Load Balancer のための加重ターゲットグループを発表します。これは、開発者がアプリケーションの複数バージョンにトラフィックをどのように分散させるかを制御できるようにします。 複数の加重ターゲットグループ 複数のターゲットグループをリスナールールの forward アクションに追加し、各グループの重みを指定することができるようになりました。例えば、8 および 2 の重みを持つ 2 つのターゲットグループがあるルールを定義すると、ロードバランサーはトラフィックの 80% を最初のターゲットグループに、20% をもう一方のターゲットグループにルーティングします。 今すぐ加重ターゲットグループで実験するには、この CDK コードを使用できます。これは、EC2 インスタンスと、それらの前にある Elastic Load Balancer で 2 つの Auto […]

アマゾン ウェブ サービスは 2006 年以来、IT インフラストラクチャの簡略化に努力してきました。Amazon Elastic Compute Cloud (EC2)、Amazon Simple Storage Service (S3)、Amazon Relational Database Service (RDS)、AWS CloudFormation など多数のサービスのおかげで、数百万ものお客様が AWS リージョンであればどこでも信頼性の高いスケーラブルでセキュアなプラットフォームをわずか数分で構築できるようになりました。10 年にわたって多数のハードウェアを調達、デプロイ、管理してきましたが、AWS のサービスを使用してビルダーたちが成し遂げてきたイノベーションのペースには毎日驚くばかりです。 巨大なパワーには巨大な責任が伴います。AWS リソースを作成したその瞬間に、セキュリティのほかにコストやスケーリングに対する責任が生じます。何よりもモニタリングとアラートが重要となるため、Amazon CloudWatch、AWS Config、AWS Systems Manager などのサービス展開のきっかけになりました。 ところが、お客様は、作成したアカウントやリージョンに関係なく、1 つのダッシュボードで AWS リソースに起こる可能性のある問題を一覧表示できればオペレーションがもっと簡単になることを期待されていました。 そこで、さっそく着手しました。そして本日ここに、Systems Manager の一元管理オペレーションダッシュボードである AWS Systems Manager Explorer の提供開始をお知らせします。 AWS Systems Manager Explorer のご紹介 EC2、Config、CloudWatch、Systems Manager からモニタリング情報やアラートを収集する AWS Systems Manager Explorer […]

AWS Step Functions を使用すると、アプリケーションにサーバーレスワークフローのオートメーションを追加できます。ワークフローのステップは、 AWS Lambda 関数、Amazon Elastic Compute Cloud (EC2)、またはオンプレミスなど、どこでも実行可能です。ワークフローの構築を簡略化するために、Step Functions は AWS の複数のサービス (Amazon ECS、AWS Fargate、Amazon DynamoDB、Amazon Simple Notification Service (SNS)、Amazon Simple Queue Service (SQS)、AWS Batch、AWS Glue、Amazon SageMaker、および (ネストされたワークフローを実行するために) Step Functions 同士) と直接統合されています。 本日より、Step Functions は Amazon EMR に接続されました。これにより、最小限のコードでデータ処理および分析ワークフローを作成して、時間の節約、クラスターの使用の最適化を実現することができます。たとえば、機械学習用のデータ処理パイプラインの構築は時間がかかり、困難です。この新しい統合により、並列実行や前のステップにおける結果からの依存関係といったワークフロー機能のオーケストレーションや、データ処理ジョブを実行する際の障害および例外の処理が簡単になります。 具体的には、Step Functions ステートマシンで以下のことができるようになりました。 EMR クラスターの作成、終了 (クラスターの終了保護の変更も可能)。これを行うと、既存の EMR クラスターをワークフローで再利用したり、ワークフローの実行中にオンデマンドで作成したりできます。 クラスターの EMR ステップの追加、キャンセル。 EMR ステップは、クラスターにインストールされたソフトウェア (Apache、Spark、Hive、または Presto といったツールなど) […]

本日、AWS DataSync は、オンプレミスストレージから Amazon S3 または Amazon Elastic File Service (Amazon EFS) にデータを移動するお客様を支援する 3 つの拡張機能をリリースしました。DataSync は re:Invent 2018 で開始され、移行、処理、保護のために、AWS の内外にデータを移動するときにお客様が直面する一般的な課題を克服します。DataSync は、スクリプトの作成、保守、監視、ネットワークの最適化、データの整合性の検証など、データ転送に関連する多くの手動タスクを自動的に処理します。 AutoDesk や Cox Automotive などの企業は、数百テラバイト、さらにはペタバイト単位に及ぶオンライン転送でこのサービスを利用しています。そして、DataSync チームは、開始以来、特にフィルタリング、SMB ファイルの共有のサポート、VPC エンドポイントの追加など、お客様のリクエストに基づいた革新に忙しく取り組んでいます。 それでは、今回の改善点を掘り下げてみましょう。 DataSync は、料金を 68% 下げて、AWS との間でコピーされるデータのギガバイトあたり 0.0125 USD にしました。DataSync の料金はシンプルです。データの移動に対して、前払い料金や最低請求額なしで、GB 単位のフラットな料金をお支払いいただきます。今回の料金引き下げにより、データの AWS への移行はますます手頃な料金になります。また、Amazon EFS のリージョン間およびアカウント間でのレプリケーション、集中型 Amazon S3 バケットとの間でのメディア配信など、他のユースケースのコスト効率も高まります。リージョンから転送されたデータ、またはリージョン間で転送されたデータの AWS 標準請求にご注意ください。これらの料金は、データのコピー元のサービスの料金ページに詳細が記載されており、リージョンによって異なります。 リージョンについて言うと、DataSync はさらに 5 つのリージョンで利用可能になりました。具体的には、本日、DataSync は欧州 (ストックホルム)、南米 […]

概要 今日では、多数のお客様に、事業活動に必須のアプリケーションとして AWS Storage Gateway をご利用いただいています。iSCSI、NFS、SMB、iSCSI VTL などの一般的なストレージプロトコルを提供することにより、Storage Gateway は、事実上無制限のクラウドストレージの恩恵を受けながら、お客様が既存のアプリケーションを容易に継続できるようにしています。お客様は、Storage Gateway を使用して、ストレージ管理を簡素化し、ハイブリッドなクラウドストレージの 3 つのユースケースの費用を削減できます。そのユースケースとは、オンプレミスのバックアップのクラウドへの移動、クラウドベースのファイル共有によるオンプレミスストレージの削減、そして、オンプレミスアプリケーションの AWS にあるデータへの低レイテンシーのアクセスの提供です。 今年、Storage Gateway は、数々の機能を立ち上げ、お客様の最も重要なアプリケーションについて、増加の一途を辿るニーズへの対応をサポートしてきました。本日、私たちは、Storage Gateway High Availability (HA) on VMware を立ち上げました。これにより、メディアデバイス、ストリーミングログリポジトリ、科学機器のストレージなど、中断されてはならず、遅延の影響を受けやすいワークロードの運用ニーズに対応します。 AWS Storage Gateway の多くのお客様は、VMware vSphere のクラスターでゲートウェイをデプロイし、実行しています。高可用性の新機能により、これらのお客様は、高可用性のニーズがあり、中断されてはならないアプリケーションについて、AWS Storage Gateway の利用を拡大することができるようになりました。ヘルスチェックを VMware vSphere High Availability (vSphere HA) に統合することを通じて、オンプレミスの VMware 環境または AWS の VMware CloudTM でデプロイされた Storage Gateway は、ハードウェア、ハイパーバイザー、ネットワークの障害、ストレージのエラー、接続タイムアウトやファイル共有またはボリュームが利用不能であることなどのソフトウェアのエラーからストレージワークロードを保護しつつ、データを消失することなく、60 秒もかからずに、ほとんどのサービスの中断から自動的に復旧します。これにより、ヘルスチェック、自動的な再起動、アラートについてのカスタムスクリプトが不要になります。 さらに、新しいヘルスチェックは、vSphere HA VM と […]

この投稿は Otavio Ferreira, Sr Manager, SNS の寄稿によるものです 郵便システムにおいて、デッドレターキューは配信不能な郵便物を取り扱うための施設です。pub/sub メッセージングモデルにおけるデッドレターキュー (DLQ: dead-letter-queue) は、トピックに対して発行されたメッセージがサブスクライブしているエンドポイントに配信できなかった場合に、そのメッセージを送ることができるキューを表します。 Amazon SNS による DLQ サポートによって、アプリケーションはメッセージ配信における各種故障モードに対する、さらなる耐久力と回復力を持つことが可能になりました。 メッセージの配信失敗と再試行を理解する Amazon SNSがサブスクライブされたエンドポイントにアクセス出来ない場合、メッセージの配信は失敗します。このような状況は大きく2つの原因によって引き起こされます: クライアントエラー。ここでクライアント (メッセージ送信者) は SNS となります。 サーバーエラー。ここではサーバーは、例えば Amazon SQS や AWS Lambda のようにサブスクリプションのエンドポイント (メッセージ受信者) をホストするシステムとなります。 クライアントエラー クライアントエラーは、 SNS の保持しているメタデータが最新ではない場合に発生します。クライアントエラーの発生するよくある原因としては、エンドポイントの所有者がエンドポイントを削除した場合が挙げられます。例えば SNS に紐付いたサブスクリプションを削除することなく、SNS トピックにサブスクライブした SQS キューを削除してしまったような場合です。やはりよくある別の例としては、エンドポイントに適用されたポリシーに対して、SNS がメッセージを配信することを阻害するような変更を加えてしまった場合が挙げられます。 これらのエラーは、クライアントがメッセージの配信を試みたにもかかわらず、クライアントの視点からエンドポイントがアクセス不能となっていることが原因で発生するため、クライアントエラーとして取り扱われます。SNS はクライアントエラーの結果として失敗したメッセージの配信を再試行することはありません。 サーバーエラー サーバーエラーは、サブスクライブしているエンドポイントを実行しているサーバーが利用できないか、または SNS からの有効なリクエストを処理できなかったことを表す例外応答を返した場合に発生します。 サーバーエラーが発生した場合、SNSは線形、指数的のいずれかのバックオフ機能に基づいて配信を再試行します。SQS や Lambda 上で実行される AWS […]