Amazon Web Services ブログ

大阪でのサービスに対するお客様からの大きなご要望にお応えし、大阪のローカルリージョンが 2021 年初頭までに 3 つのアベイラビリティーゾーンを持つ完全な AWS リージョンに拡大することになりました。 他のすべての AWS リージョンと同様、アベイラビリティーゾーンはそれぞれ独自の電源、冷却システム、物理的セキュリティにより分離されます。また、可用性に影響を与える単一のイベントのリスクを大幅に減らすため離れて配置されますが、高可用性アプリケーションの低レイテンシーは維持されます。 AWS はインフラストラクチャを継続的に拡張しており、お客様が拡大できる十分な能力と、可用性と堅牢性を高めるためのさまざまなシステムを設計するために必要なツールを提供しています。AWS は現在、22 のリージョンと 69 のアベイラビリティーゾーンをグローバルに運用しています。 2011 年 3 月に、2 つのアベイラビリティーゾーンを持つ 5 番目の AWS リージョンとして AWS 東京リージョンを立ち上げました。その後、2012 年に 3 番目の東京のアベイラビリティーゾーン、2018 年に 4 番目のアベイラビリティゾーンを立ち上げました。 2018 年 2 月には大阪ローカルリージョンを立ち上げました。単一のデータセンターに含まれるインフラストラクチャは分離されかつ対障害性のある設計で、既存の AWS リージョンを補完する新しいリージョン構成となりました。東京リージョンから 400 キロ離れた大阪ローカルリージョンは、東京リージョンだけでは難しい災害対策の提供を目指して、国内のさまざまな場所で必要とされるアプリケーションを持つお客様をサポートしてきました。 大阪ローカルリージョンの将来 大阪リージョンは、立ち上げ時より他の AWS リージョンと同様の幅広いサービスを提供し、あらゆる AWS のお客様が利用できるようになる予定です。お客様は日本国内にマルチリージョンシステムをデプロイすることができ、西日本のユーザーは現在よりもさらに低いレイテンシーを享受できます。 最高のグローバルネットワークパフォーマンスを備えた、最も柔軟で、信頼性が高く、かつスケーラブルでセキュアなクラウドコンピューティング環境を提供する AWS グローバルインフラストラクチャの設計と構築に関心があるお客様は、グローバルインフラストラクチャサイトをご覧ください。このサイトでは、すべてを分かりやすく説明しています。 ご期待ください 今回の件や他の今後の AWS リージョンに関する新たな情報が分かり次第、皆さまにお知らせします。どうぞご期待ください。 4 つのリージョン […]

みなさん、こんにちは。AWSソリューションアーキテクトの小林です。 次週改めてピックアップしますが、大阪ローカルリージョンを通常リージョンへ拡張する計画があることを発表させていただきました。新たに2つのアベイラビリティゾーンを設置し、利用可能なサービスのポートフォリオも拡充される予定です。現時点では2021年の早い時期にご利用いただけるようにする計画ですので、ぜひご期待ください。 それでは、先週の主なアップデートについて振り返っていきましょう。

Amazon Polly はテキストをリアルな音声に変換するサービスです。これを利用して、音声対応アプリケーションの作成が可能です。AWS は、中東 (バーレーン) およびアジアパシフィック (香港) リージョンにおいて、すべてのスタンダード音声が一般に利用可能になったことを発表しました。これらのリージョンのお客様は、Amazon Polly のポートフォリオで 29 言語でご利用いただける 60 種類を超えるスタンダード音声を音声合成できるようになりました。 Amazon Polly をご使用のお客様は、ニュースコンテンツ、ゲーム、e ラーニングプラットフォーム、テレフォニーアプリケーション、ユーザー補助アプリケーション、IoT などの音声認識対応製品という新しいカテゴリを構築しています。Amazon Polly の音声は高品質で費用対効果が高く、またレスポンスも速いため、低レイテンシーのユースケースに適しています。Amazon Polly は SSML タグもサポートしています。このため、音声出力をさらに制御できます。 詳細については、「Amazon Polly とは」をご参照ください。 利用可能な音声の完全なリストについては、「Amazon Polly の音声」をご覧ください。または、Amazon Polly コンソールにログインして、ご自分で試してみてください。 著者について Ankit Dhawan は Amazon Polly のシニアプロダクトマネージャーです。テクノロジーを愛し、Liverpool FC の大ファンです。お客様の対応をしていないときには、奥さんと愛犬とともにアメリカ太平洋岸の北西部エリアを探索しています。いつも楽観主義で、また伝記を読んだり、ポーカーをプレイするのが大好きです。テクノロジーや起業家精神、サッカーについてなら、話が尽きることはありません。  

この記事は、FactSet のリードソフトウェアエンジニアである Arvind Godbole と AWS プリンシパルソリューションアーキテクトの Tarik Makota によるゲスト投稿です。「FactSet は、世界中の何万人もの投資専門家向けの柔軟でオープンなデータとソフトウェアソリューションを作成し、投資家が重要な決定を下すために使用する金融データと分析に即座にアクセスできるようにします。FactSet では、製品が提供する価値を常に向上するために取り組んでいます」 私たちが検討してきた分野の 1 つは、クライアントの検索結果の関連性です。さまざまなクライアントの使用例と 1 日あたりの検索回数が多いため、匿名化された使用データを保存し、そのデータを分析してカスタムスコアリングアルゴリズムを使用して、結果を高めることができるプラットフォームが必要でした。計算をホストするために Amazon EMR を使用するのは明らかな選択肢でしたが、匿名化されたデータを Amazon EMR が使用できる形式に変える方法について疑問が生じました。そこで私たちは AWS と協力し、Amazon DynamoDB を使用して Amazon EMR で使用するデータを準備することにしました。 この記事では、FactSet が DynamoDB テーブルからデータを取得し、そのデータを Apache Parquet に変換する方法について説明します。Amazon S3 に Parquet ファイルを保存して、Amazon EMR でほぼリアルタイムの分析を可能にします。途中で、データ型変換に関連する課題に直面しました。これらの課題をどのように克服できたかについて説明しようと思います。 ワークフローの概要 ワークフローには次の手順が含まれています。 匿名化されたログデータは DynamoDB テーブルに保存されます。これらのエントリには、ログの生成方法に応じて異なるフィールドがあります。テーブルに項目を作成するたびに、DynamoDB ストリームを使用してレコードを書き出します。ストリームレコードには、DynamoDB テーブルの単一項目からの情報が含まれます。 AWS Lambda 関数は DynamoDB ストリームにフックされ、DynamoDB […]

本投稿は、Principal Solutions Architectである George Maoの寄稿によるものです。 AWSサーバーレスプラットフォームは、デマンドに応じて自動的に拡張するアプリケーションを構築することができます。大量アクセスがある間、 Amazon API Gateway と AWS Lambda は負荷に応じて自動的にスケールします。 多くの場合、開発者は、Lambda関数からリレーショナルデータベースに保存されたデータにアクセスする必要が出てきます。しかし、Lambdaからデータベースへの多すぎるコネクションにより過負荷にならないようにすることは難しい場合があります。リレーショナルデータベースの最大同時接続数は、データベースのサイズによって異なります。 これは、各コネクションがデータベースサーバー上のメモリとCPUリソースを消費するためです。Lambda関数は数万の同時接続数までスケールできるため、それに対応するには、データベースはクエリを実行するだけでなく、コネクションを維持するためにより多くのリソースが必要になります。 スケーリングの詳細については、アーキテクチャブログの投稿「サーバーレスアプリを大規模に設計する方法」も参照してください。 RDSを使用したサーバーレスアーキテクチャ Lambdaは数万の同時リクエストに応じて簡単にスケールできるため、そのような状況において、この設計ではバックエンドのリレーショナルデータベースに高い負荷がかかります。通常は、リレーショナルデータベースは、Lambdaのスケーラビリティに応じた同時接続を受け入れるように設計されていません。 Amazon RDSのデータベースプロキシ 本日(2019年12月3日 PST)、Amazon RDS Proxyのプレビューを発表できることを嬉しく思います。 RDS Proxyは、アプリケーションとRDSデータベースの間の仲介役として機能します。RDS Proxyは、必要となるデータベースへのコネクションプールを確立および管理し、アプリケーションからのデータベース接続を少なく抑えます。 データベースへのSQL呼び出しを行うアプリケーションには、RDS Proxyを使用できます。ただし、サーバーレスのコンテキストでは、これによりLambda利用の体験がどのように改善されるかに焦点を当てています。RDS Proxyは、Lambda関数からデータベースに直接流れるすべてのデータベーストラフィックを処理します。 Lambda関数は、データベースインスタンスではなくRDS Proxyと対話します。RDS Proxyは、Lambda関数の同時実行によって作成された大量の同時接続をスケーリングするために必要なコネクションをプーリングします。これにより、Lambdaアプリケーションは、Lambda関数呼び出しごとに新しいコネクションを作成するのではなく、既存のコネクションを再利用できます。 RDS Proxyは自動的にスケーリングされるため、データベースインスタンスでコネクション管理に必要なメモリとCPUリソースが少なくなります。また、暖機されたコネクションプールを使用することでパフォーマンス向上にもつながります。RDS Proxyを使用すると、アイドル接続のクリーンアップとコネクションプールの管理を処理するコードが不要になります。Lambda関数コードは、より簡潔でシンプルとなり、保守性が向上します。 Amazon RDS Proxyを利用してみよう Amazon RDS Proxyは、プレビューであり、留意事項がいくつかあります。 現在、MySQLバージョン5.6または5.7で実行されるAmazon RDS MySQL、または、Aurora MySQLをサポートしています。 プレビューは、アジア太平洋（東京）、EU（アイルランド）、米国東部（オハイオ）、米国東部（バージニア北部）、米国西部（オレゴン）で利用できます。 パブリックプレビュー中においては、AWSマネジメントコンソールを使用してRDS Proxyを設定する必要があります。 プレビューである事に起因した変更が発生する可能性があるため、本番ワークロードにはこのサービスを使用しないでください。 サービスの詳細な説明については、プレビューガイドを確認してください。 前提条件 Amazon RDS MySQL、または、Aurora […]

  概要 つい最近まで、ECS クラスター内での EC2 インスタンスの数を、タスクとサービスに合わせてスケーリングさせようとすると、難しい問題の発生することがありました。  ECS クラスターは必ずしも必要なときにスケールアウトするわけではなく、スケールインは注意深く扱わないと可用性に影響を及ぼします。ときには、顧客はこの課題に対応するため、Lambda 関数などのカスタムの手法、カスタムのメトリクス、そして重量挙げにも例えられるような他の手段に訴えましたが、あらゆる状況でうまくいく単一のアプローチはありませんでした。もちろん、タスクを EC2 インスタンスの代わりに Fargate で実行すれば、クラスターのスケーリングの必要性は全くなくなりのですが、すべての顧客がすべてのワークロードで Fargate を採用する用意ができている、または用意ができるわけではありません。 ECS クラスター Auto Scaling (CAS) は、EC2 Auto Scaling グループ (ASG) のスケーリングを管理する、ECS のための新しい機能です。CAS を使えば、ECS が ASG を自動的にスケーリングするように構成できるので、自分のタスクにのみ注意を集中できます。ECS は必要に応じて ASG がスケールインおよびスケールアウトできるようにします。それ以上の介入は必要ありません。CAS は、ECS クラスターとユーザーが使用する ASG の間をリンクする、ECS のキャパシティプロバイダに依存します。それぞれの ASG は 1 つのキャパシティプロバイダと関連付けられ、キャパシティプロバイダはただ 1 つの ASG を持ちますが、1 つの ECS クラスターには多数のキャパシティプロバイダを関連付けることができます。クラスター全体を自動的にスケーリングするために、それぞれのキャパシティプロバイダが、関連している ASG のスケーリングを管理します。 CAS をローンチする際の私たちの目標の 1 […]

2019 年 12 月、Amazon Elastic Kubernetes Service を使用して AWS Fargate で Kubernetes ポッドを実行できることを発表しました。Fargate を使用すると、Kubernetes アプリケーションの EC2 インスタンスを作成または管理する必要がなくなります。ポッドが起動すると、Fargate はそれらを実行するために計算リソースをオンデマンドで自動的に割り当てます。 Fargate は、マイクロサービスの実行とスケーリングに最適です。特に、スパイクが発生し、予測できないトラフィックパターンがある場合に役立ちます。Amazon Elastic Load Balancing Application Load Balancer (ALB) は、Kubernetes クラスターで実行されているポッドなど、複数のターゲット間でのアプリケーションレイヤー (レイヤー 7) で着信トラフィックを負荷分散する人気のある AWS サービスです。マイクロサービスのようなトラフィックを取得するための優れた方法です。 このブログでは、オープンソースの ALB Ingress Controller を使用して、Fargate ポッドへの入力ベースの負荷分散のために EKS クラスターで AWS Application Load Balancer (ALB) をセットアップする方法を示します。ALB Ingress Controller を使用する Kubernetes Ingress の詳細については、こちらの投稿をご覧ください。 開始するには、Amazon […]

昨年 AWS Backup をリリースして以来、毎日 20,000 を超える AWS のお客様がペタバイトのデータを保護しています。AWS Backup は、Amazon Elastic Block Store (EBS) ボリューム、データベース (Amazon Relational Database Service (RDS) または Amazon DynamoDB)、AWS Storage Gateway、Amazon Elastic File System (EFS) のバックアップ管理を簡素化する、フルマネージド型の一元管理バックアップサービスです。 私たちはお客様のご意見を引き続きお待ちしております。その結果、現在、AWS Backup にエンタープライズデータ機能を追加しています。 Amazon Elastic Compute Cloud (EC2) インスタンス全体をバックアップできるようになりました。 バックアップを他の AWS リージョンにコピーできるようになりました。 完全なファイルシステムではなく、Elastic File System ファイルシステムから単一のファイルを復元できるようになりました。 詳細は以下のとおりです。 EC2 インスタンスのバックアップ EC2 インスタンスのバックアップと復元には、インスタンスの個々の EBS ボリュームだけでなく、追加の保護が必要です。インスタンスを復元するには、すべての EBS ボリュームを復元する必要があります。また、インスタンスタイプ、VPC、セキュリティグループ、IAM […]

アプリケーションを構築または移行する際に、多くの場合、複数の計算ノード間でデータを共有する必要があります。 多くのアプリケーションはファイル API を使用し、Amazon Elastic File System (EFS) では AWS でそれらのアプリケーションを簡単に使用できます。他の AWS サービスおよびオンプレミスリソースからアクセスできる、スケーラブルでフルマネージド型の Network File System (NFS) を提供します。 EFS は、中断することなく、オンデマンドでゼロからペタバイトまで拡張します。また、ファイルを追加および削除すると自動的に拡大および縮小を行い、容量をプロビジョニングして管理する必要性を取り除きます。これを使用することにより、3 つのアベイラビリティーゾーン間で強力なファイルシステムの一貫性が得られます。EFS パフォーマンスは、必要なスループットをプロビジョニングするオプションを使用して、保存されているデータの量に応じて拡大します。 昨年、EFS チームは、EFS Infrequent Access (IA) ストレージクラスを導入することでコストの最適化に注力し、ストレージ料金が EFS 標準と比較して最大 92% 低くなりました。一定期間アクセスされていないファイルを EFS IA に移動するようにライフサイクル管理ポリシーを設定することにより、コストをすぐに削減できます。 現在、アクセスの管理、データセットの共有、EFS ファイルシステムの保護を簡素化する 2 つの新機能を導入しています。 NFS クライアントの IAM 認証と承認により、クライアントを識別し、IAM ポリシーを使用してクライアント固有の権限を管理します。 EFS アクセスポイントは、オペレーティングシステムのユーザーとグループの使用を強制し、オプションでファイルシステム内のディレクトリへのアクセスを制限します。 IAM 認証および承認の使用 EFS コンソールで、EFS ファイルシステムを作成または更新するときに、ファイルシステムポリシーを設定できるようになりました。これは、Amazon Simple Storage Service (S3) のバケットポリシーに類似した […]

スマートビルディング、ユーティリティ、製造システム、コネクテッド製品などの環境を運用するソリューションプロバイダーは、マルチテナントに展開されるIoTプラットフォームを用いたB2Bサービスを提供します。ユースケース、種類、場所、およびテナントごとにこれらのリソースを安全に管理するのは難しい場合があります。 モノの階層的なグループを作成することは一般的なパターンですが、マルチテナンシーにうまく対応していません。たとえば、同じテナントが複数の都市にオフィスを借り、他のテナントと一部の建物を共有する場合、階層的なグループを作成してこれをうまく表現することはできません。一方で、同じリソースが異なるテナント（コネクテッドビークル、賃貸オフィススペース、コネクテッドデバイスなど）によって使用される可能性があります。 この投稿では、IoTのマルチテナント展開でAWSタグを使用して、そのような環境でのAWS IoTリソースの管理とセキュリティを改善する方法について説明します。まず、リソースのタグ付けが重要である理由について説明し、次にAWS IoTのタグ付け機能について掘り下げます。そして、架空のマルチテナントスマートビルディング環境でタグを設定し、使用する手順を実行します。