Amazon Web Services ブログ

クラウドコンピューティングのメリットのひとつは、インフラストラクチャをプログラム的に作成し、必要なくなったら破棄する可能性です。これは、アプリケーションをデプロイする方法を、開発者が根本的に変えることを可能にします。オンプレミスでアプリケーションをデプロイしていた頃、開発者はアプリケーションの新しいバージョンのために既存のインフラストラクチャを再利用しなければなりませんでした。クラウドでは、開発者がアプリケーションの新しいバージョンのために新しいインフラストラクチャを作成し、古いバージョンを破棄する前にしばらく並行して実行させておきます。この手法はブルー/グリーンデプロイメントと呼ばれます。これは、アプリケーションの 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 […]

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