Amazon Web Services ブログ

ローンチニュース: AWS DataSync が料金を下げ、新しいリージョンで開始、スケジューリングを追加

本日、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 は欧州 (ストックホルム)、南米 […]

Read More

VMware vSphere クラスターに高可用性の AWS Storage Gateway をデプロイする

概要 今日では、多数のお客様に、事業活動に必須のアプリケーションとして 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 と […]

Read More

Amazon SNS, Amazon SQS, AWS Lambda のデッドレターキューによる耐久性のあるサーバーレスアプリケーション設計

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

Read More

新しいサーバーレスアプリ作成機能で CI/CD も作成した、その後…

本記事は「新しいサーバーレスアプリ作成機能で 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 […]

Read More

ポスト量子暗号 TLS が AWS KMS でサポートされました

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

Read More

真のオムニチャネルコンタクトセンター体験を実現する、Amazon Connect Web & Mobile チャットのご紹介

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

Read More

AWS re:Invent 2019 での Amazon DocumentDB (MongoDB 互換) をテーマとしたセッション、ワークショップ、チョークトークのご案内

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

Read More

S3_INTEGRATION を使用して Amazon RDS for Oracle を Amazon S3 と統合する

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

Read More

Amazon EMR が、Apache Spark 用 EMR ランタイムを導入

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

Read More

2019 年 11 月 11~15 日までの Amazon DynamoDB のローンチのまとめ

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

Read More