Amazon Web Services ブログ

この投稿は 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 […]

本記事は「新しいサーバーレスアプリ作成機能で CI/CD も作れます」のその後のステップとして記述しています。まだその記事を見ていない方は、まずはそちらをご覧ください。以下は、その機能で、テンプレートとして Serverlerss API backend を選択し、プロジェクトリポジトリとして CodeCommit を作成された結果を元に説明しています。CI/CD や CodeCommit をよくご存知の方は読み飛ばしていただいて構いません。 実行テスト 作成されたアプリケーションは、何も変更しなくてもすでに実行できる状態にあります。 例えば、ターミナルなどから以下のコマンドを実行してみてください（なお、下記のように日本語を含むデータで実行する場合は、ターミナルの文字コード設定が UTF-8 であることを確認ください）。 curl -d ‘{“id”:”001″,”name”:”テスト”}’ -H “Content-Type:application/json” -X POST https://<<API EndPoint>> DynamoDBのコンソールをみると、新しいデータが登録されることがわかります。もちろん、好みの REST API テストツール（ブラウザプラグインなど）を使っても構いません。 構成の確認 生成されたアプリケーションで、API 定義、Lambda 関数がどのように定義されているかを見るのは、サーバーレスを始めたばかりの開発者には参考になるかと思います。例えば、API Gateway の構成を見てみると、以下のように設定されていることがわかります。 名称で想像できる通り、3つの関数は、全件検索、データの書き込み、特定 ID のデータの取得のための処理であり、それらが対応する API に紐づけられています。この 3つの処理はよく使われる典型的なものですので、そのコードは、多くの処理で参考になるでしょう。 コードの編集 テンプレートベースのサーバーレスアプリ作成機能で設定された Lambda 関数がどういうものか、コンソールから確認してみましょう。作成したサーバーレスアプリケーションへ Lambda コンソールからアクセスし、その中のリソースのセクションを見ると Lambda Function タイプのものが作成されていることがわかります。 ここにあるリンクをクリックすれば、それぞれの Lambda 関数の画面に飛びますが、そのコードは表示されず、「インラインコード編集を有効にできません」と表示される場合があります。生成されたコードはどこにあるのでしょう? もう一度、Lambda […]

AWS Key Management Service (AWS KMS) が KMS API エンドポイントに接続する際に使われる Transport Layer Security (TLS) ネットワーク暗号化プロトコルにおけるポスト量子暗号ハイブリッド鍵交換をサポートしました。この投稿では、ポスト量子暗号 TLS とは何か、 ハイブリッド鍵交換とは何か、 なぜこれらの技術が重要か 、この機能でどのようなメリットを得られるのか、そしてフィードバックの方法について説明します。 ポスト量子暗号 TLS とは? ポスト量子暗号 TLS は、ポスト量子暗号の暗号プロトコルを追加する機能です。 AWS はオープンソースの TLS 実装である s2n を使用しています。2019年6月に AWS はポスト量子暗号 s2n をリリースしました。これは、IETF ドラフトで定義されている２種類のポスト量子暗号ハイブリッド暗号スイートを実装しています。暗号スイートは、従来型とポスト量子暗号の両方のセキュリティ保護を行う暗号鍵交換方式を指定するものです。 ポスト量子暗号 TLS の重要性 大規模な量子コンピュータは、TLS 接続の暗号鍵交換で使用されている既存の公開鍵暗号を破る可能性があります。大規模な量子コンピューターは現時点で利用可能ではありませんが、長期的なセキュリティ保護のニーズについて考え、準備しておくことが重要です。記録された TLS トラフィックは将来的に大規模な量子コンピュータで復号出来る可能性があります。TLS 接続の上で送信されているデータの長期間の機密性維持が必要なアプリケーションを開発している場合、大規模な量子コンピュータが実用化され、悪意を持った人に利用可能になる前にポスト量子暗号に移行することを検討するべきでしょう。AWS はこの機能の提供について取り組んでおり、お客様にも準備して頂きたいと考えています。 AWS は大規模な量子コンピュータの実現を待つのではなく、今この機能を提供します。 お客様は、アプリケーションに対する潜在的なパフォーマンス影響を計測することが可能です。また、お客様は、ポスト量子暗号スキームによってもたらされる追加の利点を得ることが可能です。AWS はこの機能が既に存在する KMS エンドポイントへの接続に関するセキュリティーのバーを向上させると考えていると共に、新しい暗号スイート帯域利用率やレイテンシに影響を与えると考えています。また、TLS 接続を中継する中間システムにも影響を与える可能性があります。将来に渡るサービスの改善のために AWS はこれらのお客様環境における影響についてフィードバックして頂きたいと考えています。 ポスト量子暗号 […]

1995年にAmazonをスタートしたとき、地球で最も顧客中心の企業であることが我々の使命でした。そのビジョンを実現するには、コンタクトセンターを含め、多くの有能な個人や技術が必要なことは明らかです。Amazonの小売事業が拡大するにつれ、当初はサードパーティのコンタクトセンターソリューションを利用していましたが、私たちのニーズに合ったソリューションが見つからなかったため、独自のソリューションを開発・構築することにしました。初期バージョンを構築した後、コンタクトセンターチームのフィードバックに耳を傾け、セキュリティ、弾力性、柔軟性、信頼性、高い顧客満足度基準といった厳しい要件を満たすために改良を数年間繰り返しました。多くのAWSのお客様は、コンタクトセンターの調達、インストール、設定、運用において、我々と同じ課題があると語っており、このソリューションをすべての企業に利用できるようにとのリクエストを受けていました。

AWS re:Invent 2019 がもうすぐ開催されます。 この記事には、AWS re:Invent 2019 で行われる、Amazon DocumentDB (MongoDB 互換) をテーマとしたセッション、ワークショップ、チョークトークの全リストを掲載しています。このページの情報を利用して、ラスベガスでの 1 週間のスケジュールを立て、Amazon DocumentDB の知識を蓄えてください。 セッション、ワークショップ、チョークトーク DAT326 – Amazon DocumentDB の詳細情報 (セッション) 開発者たちは、アプリケーションをより迅速に構築、進化させることができるという理由から、MongoDB API の柔軟なスキーマと表現力豊かなクエリ言語を導入しています。しかし、中にはデータベースの管理は時間がかかり、複雑であり、スケーリングが難しいことを認識している開発者もいます。Amazon DocumentDB (MongoDB 互換) で提供されている高速かつ信頼性が高いフルマネージド型 MongoDB 互換データベースサービスを使用すると、時間のかかるセットアップや管理タスクが排除され、開発者は高性能でスケーラブルなアプリケーションの構築に集中できるようになります。Amazon DocumentDB の詳細や、フルフィルメント by Amazon (FBA) における Amazon DocumentDB を使用したビジネス効率化の方法、および MongoDB ワークロードを大規模に運用する方法を知りたい方は、こちらのセッションにご参加ください。 DAT338-R – 実践的ワークショップ: Amazon DocumentDB への移行方法 (ワークショップ) Amazon DocumentDB は、高速で信頼性が高い、フルマネージド型の MongoDB 互換データベースサービスです。現在 MongoDB を使用している場合、ワークロードを Amazon DocumentDB […]

Amazon RDS for Oracle では、マネージドサービスソリューションのあらゆる利点を活用できます。リフトアンドシフトアプローチを使用してレガシー Oracle データベースを Amazon RDS for Oracle に移行すると、既存のアプリケーションコンポーネントをリファクタリングしたり変更したりする必要性を減らすことができます。 データウェアハウス (DW) 抽出は、ほとんどのデータベースにおいて不可欠な部分です。データベースのホストと社内データベース用 DW サーバーとの間で、ネットワークファイルシステム (NFS、Network File System) などの共有ファイルシステムに抽出ファイルを保持するのが一般的な方法です。 DW ロード用の共有ファイルシステムを使用してオンプレミスの Oracle から Amazon RDS for Oracle への移行を行う際には、既存の共有転送メカニズムがスムーズに移行できるかという点に特に注意する必要があります。そのことを念頭に置いて、AWS は 2019 年 2 月に、Amazon S3 統合により Amazon RDS for Oracle を強化しました。このオプションにより、Amazon RDS for Oracle Database を Amazon Simple Storage Service (Amazon S3) にシームレスに統合することができます。 この記事では、アプリケーションホストとAmazon […]

Amazon EMR は、Apache Spark 用の Amazon EMR ランタイムを発表いたします。これは、Amazon EMR クラスターでデフォルトでアクティブになっている Apache Spark 用のパフォーマンス最適化ランタイム環境です。Spark 用の EMR ランタイムは、EMR 5.16 と比べて最大 32 倍高速で、オープンソース Spark と 100% の API 互換性があります。これは、アプリケーションに変更を加えることなく、ワークロードがより速く実行され、コンピューティングコストを節約できることを意味します。 Amazon EMR は EMR 5.24 以降、Spark ランタイムの改善を追加しており、Spark パフォーマンスの最適化で説明しています。EMR 5.28 には、さらにいくつかの新しい改善も含まれています。 こうした改善を評価するために、EMR 5.16 (オープンソース Apache Spark バージョン 2.4 と使用) と EMR 5.28 (Apache Spark バージョン 2.4 互換 Apache Spark 用 […]

Amazon DynamoDB は、先週 6 つの主要なローンチを行いました。この投稿では、各ローンチの概要を記載しており、すべての新情報を知るのに役立ちます。これらのローンチには、利用可能リージョンの拡大および機能の更新を含みます。これらのローンチについて質問がある場合は、Twitter で@DynamoDB までメッセージをお送りください。 11 月 11 日 (月) Amazon DynamoDB Accelerator (DAX) が欧州 (ロンドン) および欧州 (パリ) の各リージョンで利用可能に DAX が欧州 (ロンドン) および欧州 (パリ) の各リージョンで利用可能になりました。これらの AWS リージョンでは、マイクロ秒のレイテンシーを必要とするアプリケーションのために、Amazon EC2 R4 および T2 インスタンスタイプを用いて、DAX クラスターを作成できます。DAX は、完全に管理された、高可用性のインメモリキャッシュを Amazon DynamoDB に提供します。これにより、DynamoDB からの読み取りを最大 10 倍加速でき、毎秒 100 万リクエストの速度も可能となります。 11 月 12 日 (火) NoSQL Workbench for Amazon DynamoDB がDynamoDB […]

CloudFormation は 2011 年に開始され (AWS CloudFormation – Create Your AWS Stack From a Recipe)、多くの AWS のお客様にとって不可欠なツールになりました。お客様は、テンプレート を一度定義すると、それを使用して AWS リソースを確実にプロビジョニングできるという事実を気に入っています。また、変更セットも頻繁に使用し、変更セットの実行時に行われるアクション (追加、変更、削除) に対する洞察を得るために利用しています。 過去に書いたように、CloudFormation では、一貫性があり、安定していて、均一なモデルを実装するために特別な注意を払っています。これは CloudFormation の重要でありながら見過ごされがちな要素ですが、お客様から高く評価されていると言われています。 それでは、お客様から最も頻繁にある要求のいくつかを見てみましょう。 パフォーマンス – 過去 1 年間、CloudFormation スタックで実行されるオペレーションの数は四半期ごとに 30% 増加しました！ 開発チームは、アーキテクチャの改善と低レベルの最適化の組み合わせによって、勢いよく使用量が増えても CloudFormation をより速く、より効率的にするために絶え間なく取り組んできました。過去 2～3 か月間、この作業により、CloudFormation に関連する多くのソフトおよびハードの限界が引き上げられ、作成および更新オペレーションの平均および最大レイテンシーが大幅に低減されました。 カバレッジ – 新しいサービスや新機能を非常に迅速にリリースしていますが、時には CloudFormation がサポートされていない場合もあります。私たちの目標は、可能な限り迅速に新しいサービスと新しい機能をサポートすることであり、私たちは進歩を遂げていると確信しています。また、新しい CloudFormation Coverage Roadmap を開発プロセスへの主要な情報源として使用しており、すでに 43 の問題に対処しています。 拡張性 – CloudFormation を広範囲に使用しているお客様は、AWS […]

AWS では、EC2 インスタンスで皆さんにより優れたパワーとより多くの選択肢をお届けすべく準備を進めています。 間もなく、最大 3.3 Ghz の周波数で稼働する、カスタマイズされた第二世代 AMD EPYC 「Rome」プロセッサ搭載の C5a および C5ad インスタンスがローンチされます。これらのコンピューティング最適化インスタンスは、バッチ処理、分散型分析、ウェブアプリケーション、およびその他のコンピューティング集約型ワークロードを実行するために使用できるようになります。M、R、および T ファミリーの既存の AMD 駆動インスタンスと同様に、C5a および C5ad インスタンスは AWS Nitro System 上に構築されており、コストとパフォーマンスに基づいてインスタンスの組み合わせのバランスを取る機会を提供します。 これらのインスタンスは 8 個のサイズに加えてベアメタル型でも利用でき、最大 192 個の vCPU と 384 GiB のメモリを備えています。C5ad インスタンスには最大 7.6 TiB の高速なローカル NVMe ストレージが含まれているため、ビデオエンコーディング、画像処理、およびその他のメディア処理ワークロードに最適です。 ベアメタルインスタンス (c5an.metal および c5adn.metal) は、同等のインスタンスの 2 倍のメモリ量と 2 倍の vCPU 数を提供するため、過去最大で最も強力なコンピューティング最適化インスタンスになります。ベアメタルタイプは、100 Gbps のネットワーク帯域幅にアクセスでき、Elastic Fabric […]