Amazon Web Services ブログ

新しい AWS Auto Scaling – クラウドアプリケーションのための統合スケーリング

これまで、とても長い間、サーバーやその他のクラウドリソースのスケーラビリティについてお話ししてきました!2006年には、「新しいスケーラブルの世界、オンデマンドのWebサービスで必要なものだけにお金を支払って、無駄な出費をしない」という投稿をしました。これを簡単に行えるように、Amazon Elastic Compute Cloud (EC2) のローンチ直後に、Elastic Load Balancing、EC2 Auto Scaling、および Amazon CloudWatch を同時にローンチしました。それ以降、Auto Scaling をECS、Spot Fleets、DynamoDB、Aurora、AppStream 2.0、EMRなどのその他の AWS サービスにも追加してきました。また、アプリケーションに最も適したメトリクスに基づくスケーリングを容易にするために、ターゲットトラッキングなどの機能も追加してきました。 AWS Auto Scaling の紹介 AWS Auto Scaling の導入により、複数の AWS サービスの Auto Scaling 機能を単一のユーザーインターフェイスで簡単に使えるようになっています。既存のサービスに固有のスケーリング機能を、この新しいサービスの構築で統合しています。AWS CloudFormation スタックで説明されているように、アプリケーションの一部である、それぞれの EC2 Auto Scaling グループ、EC2 Spot Fleet、ECS タスク、DynamoDB テーブル、DynamoDB Global Secondary Indexe、および Aurora Replica、あるいは AWS Elastic Beanstalk で動作します (AWS Auto Scalingで使用するアプリケーションとして、一連のリソースにフラグを立てるためのいくつかの他の方法も検討中です)。 リソースとサービスごとにアラームとスケーリングのアクションを設定する必要はなくなりました。お使いのアプリケーションで […]

Read More

Microsoft Excel を使った Amazon Lex チャットボットの構築

この記事は、AWS コミュニティヒーローの Cyrus Wong によるゲスト投稿です。 ここ香港にある私たちの学院 (IVE) では、教育、研究、およびヘルスケアにおいて Amazon Lex での実験を開始しました。当学院には、IVE の英語教師、IVE の保育、高齢者およびコミュニティサービス学科のセラピストなど、Amazon Lex コンソールで自然言語での対話ボットを作成する技術的ノウハウを持たない従業員が多数存在します。私たちは、非技術系ユーザーのための Amazon Lex チャットボットを構築する試験的なプロジェクトをいくつか完了しました。非技術系ユーザーは Excel スプレッドシートにそれぞれの質問を記入し、その後開発者が Amazon Lex コンソールにユーザーの質問をコピーしました。しかし、ユーザーがチャットボットで何かを変更したい場合、開発者はいつもこれと同じコピーアンドペーストプロセスを行わなければなりませんでした。 そこで私たちは、「チャットボットの構築に Excel を直接使ってコピーアンドペーストの繰り返し作業をやめたらどうだろう?」と考えました。 当学院の従業員は全員 Microsoft Excel の使用方法を知っているため、私たちは最小限のプログラミングスキルでチャットボットを作成するために Excel を使用できる「ExcelLexBot」というプロジェクトを立ち上げることにしました。 ExcelLexBot は、事前定義されたフォーマットの Excel ファイル (xlsx) を Amazon Lex チャットボットに変換するサーバーレスアプリケーションです。私たちが作り上げた ExcelLexBot は様々な方法で使用することができ、その全てが迅速に、最小限の開発スキルで構築できるように設計されています。私のような教師は、ExcelLexBot を使ってインタラクティブなチャットに似たテストや課題を作成することができます。生徒は、最後の学年末プロジェクトにチャットボットの機能性を追加するためにこれを使用しますが、これも迅速に行うことができます。クラウドおよびデータセンター管理の副学士課程に属する 80 人の生徒たちが 1 時間内で 80 のチャットボットを作成しました。 この記事では、ExcelLexBot の仕組みと、それをデプロイして使用する方法について説明します。 Amazon Lex のコンセプト […]

Read More

ロンドンに 3 番目の AWS アベイラビリティーゾーンを開設

AWS を拡大するにあたり、まず地域 (リージョンと呼びます) を決定した後、その地域において複数の独立したアベイラビリティーゾーンを開設します。各アベイラビリティーゾーン (AZ) には、数多くのインターネット接続と電源接続があり、さまざまなグリッドにつながっています。 このたび、50 番目の AWS アベイラビリティーゾーンを開設することになりました。新しいゾーンは、欧州 (ロンドン) リージョンにおける 3 番目のゾーンです。これにより、極めてスケーラブルで耐障害性の高い用途をより柔軟に設計し、イギリス国内の複数の AZ で実行できるようになります。 欧州 (ロンドン) リージョンの開設以来、AWS は新しく革新的な用途でますます多くのお客様に利用されています。特に、公共機関や規制の厳しい業界においてこの傾向は顕著です。たとえば、イギリスの AWS 部門の担当者から、次のような事例の報告を受けています。 企業 – BBC、BT、Deloitte、Travis Perkins など、イギリスの大手有名企業が AWS を利用してビジネスを一変させています。イギリスの大手建材業者である Travis Perkins は、データセンターをまるごと AWS に移行するなど、そのシステムとビジネスにおいてこれまでにない規模の変革を実施しています。 スタートアップ – 国際送金サービスの Currencycloud は、支払業務とデモプラットフォームをすべて AWS に移行し、インフラストラクチャのコストを 30% 削減しています。クレジットスコア業界に新風を吹き込む Clearscore は、自社プラットフォームをすべて AWS でホスティングしています。UnderwriteMe は欧州 (ロンドン) リージョンを使用し、引受業務のプラットフォームをマネージドサービスとしてお客様に提供しています。 公共機関 – Met Office は […]

Read More

AWS DMS と Amazon Kinesis Data Firehose を利用した Aurora PostgreSQL データベースへのストリームデータのロード

AWS Database Migration Service (AWS DMS) を利用することで、様々なデータソースから商用データベースやオープンソースデータベースへとデータを移行できます。このサービスでは、Oracle Database から Oracle Database への移行といった同一のDBMS製品間での移行をサポートしています。また、Oracle Database から Amazon Aurora, Microsoft SQL Server から MySQL へといった異なるプラットフォーム間での移行もサポートしています。さらに、ストリーミングデータを Amazon S3 から Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, SQL Server を含む様々な移行先へ配信することが可能です。 Amazon Kinesis Data Firehose は、AWS へストリーミングデータをロードする上で、最も簡単な方法です。ストリーミングデータのキャプチャ、変換を行い、Amazon Kinesis Data Analytics, Amazon S3, Amazon Redshift, Amazon Elasticsearch Service へロードできます。Firehose を利用することで、すでに利用しているビジネスインテリジェンスツールやダッシュボードを使い、ニアリアルタイム分析が可能となります。Firehose はお客様が送信するデータのスループットに合わせて自動的にスケールするフルマネージドサービスで、継続した運用管理を必要としません。Firehose は、ロード前にデータをまとめ、圧縮し、暗号化することで、ロード先のストレージで必要な容量を最小化したり、セキュリティを向上させたりすることができます。 AWS DMS […]

Read More

AWS CloudTrail が Amazon SageMaker で利用可能に

以前より AWS をご利用のお客様からは、ガバナンスとコンプライアンスのニーズを満たすため Amazon SageMaker でアクティビティを記録したいというご要望をいただいておりました。このたび、Amazon SageMaker が AWS CloudTrail と統合されたことをご案内いたします。これにより Amazon SageMaker API のアクティビティに関するアカウント情報を記録して継続的にモニターして保持できるようになりました。Amazon SageMaker API コールは、Amazon SageMaker SDK、AWS SDK、Amazon SageMaker 用の Apache Spark SDK、Amazon SageMaker コンソールからキャプチャされ、Amazon S3 バケットに配信されて、AWS アカウントアクティビティのイベント履歴を提供します。記録される情報は、送信元 IP アドレス、リクエストされた日時、リクエストに関連付けられたユーザー ID、リクエストされたパラメーターなどです。 AWS CloudTrail との統合により、Amazon SageMaker には一連の管理機能が追加されます。これは、Amazon が共有セキュリティおよびコンプライアンスにおける責任を果たすための継続的な取り組みの一環です。この機能は Amazon が先月配信した管理機能に基づくものであり、ISO 標準認定に準拠しています。また、Amazon SageMaker におけるガバナンスを重視し、監査に対応した将来的機能の基盤であるとともに、お客様が安全かつ標準準拠の機械学習 (ML) プラットフォームを確立して運用するのに役立ちます。 詳細については、「Amazon SageMaker ドキュメント」を参照してください。 その他の参考資料 Amazon SageMaker でのご利用開始: より正確な時系列予測のための […]

Read More

SAP HANA Dynamic Tiering – AWSクラウド上で検証済み、およびサポート開始

この記事は、Amazon Web Services(AWS)でSAP Solutions Architectを務めるSomckit KhemmanivanhとRahul Kabraによるものです。 私たちは、パートナーであるSAP社と緊密に連携しており、AWSクラウド上でのSAP HANA Dynamic Tieringを検証してきました。AWSがSAP HANA Dynamic Tieringのプラットフォームとしてサポートされたことを発表でき、非常に嬉しく思います。SAP HANA Dynamic Tiering Product Managerを務めるCourtney Claussenの発表もご覧ください。ここでは、Dynamic TieringとAWS上での活用におけるメリットについて詳しく説明します。 SAP HANA Dynamic Tieringにより、SAP HANAデータベースは、Dynamic Tieringのサービス(esserver process)を稼働している別の専用ホスト上にウォームデータを格納できるようになります。Dynamic Tieringを使用すると、ウォームデータを格納して処理するためのマルチストアおよび拡張テーブルを作成できます。 Dynamic Tieringには以下の3つの大きなメリットがあります: 頻繁にアクセスされない古いデータを統合ディスク層にオフロードできます。 優れたパフォーマンスでディスク層のデータにアクセスできます。 SAP HANAシステムの総所有コスト(TCO)を大幅に削減します。 Courtney Claussenが、少し前にDynamic Tieringの非常に魅力的なユースケースについてのブログ記事を公開しています。電力・公益事業のお客様の請求処理の一環として、500万レコードが処理されました。これらのレコードは、SAP HANAだけで実行しているときには53分で処理できました。このベースラインが確立された後、500万レコードの25%をDynamic Tieringのマルチストアテーブルに移行しました。その結果、テーブル行の75%がSAP HANAに配置され、残り25%がDynamic Tieringに配置されます。請求処理を再度繰り返した結果、合計実行時間は58分、つまり実行時間はわずか10%の低下に留まっており、これは大幅な低コスト化をしつつ、ほぼ同等の性能を実現できることを意味します。 これらの驚くべき結果とお客様からのフィードバックが、SAP社と緊密に連携してAWSクラウド上のSAP HANA Dynamic Tieringを検証する動機になり、現在、AWSのお客様はこのサービスのパフォーマンス、コスト削減、および今後のイノベーションの恩恵を受けることができます。 AWSでは、認定されたSAP HANAシステム(244 GiB RAMから最大4 TiB RAMまでの範囲)を小規模から始め、要件の変更に応じて規模を拡大することができます。同様に、Dynamic Tieringでも、ニーズ、ワークロード、ユーザー、およびトラフィックパターンの変更に応じて、小規模から始めて容量を追加していくことができます。例えば、4 TiBのSAP HANAシステムを使用している場合、私たちが検証済みの488 […]

Read More

AWS FinTech リファレンス・アーキテクチャー日本版の公開について

アマゾン ウェブ サービス(以下 AWS )は、日本の金融機関の皆様が参照される FISCのガイドライン や PCI DSS, ISO27001, ISO27017 などの様々な統制やセキュリティ基準への対応をしてきました。現在ではグローバルに世界各国の金融機関やFinTech のお客様にAWS のサービスをご活用いただいております。この度そうした知見や実績を活かし、日本の金融機関やFinTechのお客様が主に参照される各種のガイドラインの主要な要求事項と技術的検討が必要な項目を網羅的に確認し、「AWS FinTech リファレンス・アーキテクチャー 日本版」を作成し、本日AWSコンプライアンスWEBサイトの日本のFinTech向けのページにて公開しました。お客様は、このアーキテクチャーを活用することにより、 AWS 上に FinTech サービスの環境の構築を迅速に実現する、あるいは、既存環境に関連したセキュリティや統制についての確認を行うことが可能となります。 今回の取り組みは「AWS FinTech リファレンス・アーキテクチャー日本版のホワイトペーパー」、「AWS FinTech リファレンス・ガイド 日本版」、「AWS FinTech リファレンス・テンプレート 日本版」の3つの要素で構成されています。

Read More

Amazon RDSのリードレプリカがMulti-AZ配置をサポートしました

本日より、Amazon RDS for MySQL, MariaDBのリードレプリカがMulti-AZ配置をサポートしました。Multi-AZ配置を設定したリードレプリカを利用することによって、データベースエンジンのアップグレードプロセスの簡素化やディザスタリカバリを見据えた環境を構築することが可能になります。 Amazon RDSのリードレプリカは1つ以上の読み込み専用のデータベースインスタンスをマスターインスタンスと同一のAWSリージョン、もしくは異なるAWSリージョンに作成することが出来ます。ソースデータベースで行われた変更は非同期でリードレプリカへ伝播されます。読み込みが多いワークロードに対するスケーラビリティに加えて、リードレプリカを必要に応じて単一のデータベースインスタンスへ昇格させることも可能です。 Amazon RDS Multi-AZ配置は1つのAWSリージョン内での可用性を向上させます。Multi-AZ環境では、異なるアベイラビリティゾーン(AZ)に存在するスタンバイインスタンスに対してデータが同期的に伝播されます。インフラストラクチャの障害が発生した場合、Amazon RDSはスタンバイインスタンスへ自動的にフェイルオーバーを行い、アプリケーションへの影響を最小限に抑えます。 本番データベースへのディザスタリカバリ(DR)対応として、Multi-AZ配置のリードレプリカをお使いいただけるようになりました。よくデザインされ、テストされたDRプランは災害が発生した後の事業継続性に対して非常に重要な要素になります。ソースデータベースとは別のリージョンにある、リードレプリカをスタンバイ・データベースとして使用し、万が一リージョン障害が発生した場合に新しい本番データベースへ昇格することが可能です。 また、データベースエンジンのアップグレードプロセスにMulti-AZ配置のリードレプリカを利用可能です。本番データベースにリードレプリカを作成し、新しいデータベースエンジンバージョンへ更新します。アップグレードが完了した後に、アプリケーションを一時的に停止し、リードレプリカを単一のデータベースインスタンスとして昇格させます。そして、アプリケーションの接続先を変更します。既に昇格したデータベースインスタンスはMulti-AZ配置になっているため、追加の作業は必要ありません。 更に詳細な情報はこちらをご覧ください。リードレプリカでMulti-AZ配置を行う際に注意していただきたいパラメータについて記載しています。   翻訳は星野が担当しました。(原文はこちら)

Read More

CES におけるコネクテッドカーのための AWS IoT、Greengrass、および AWS Machine Learning

わたしは先週、シアトルを拠点とする INRIX 社社長、ブライアン・ミストル氏の講演を聞きに行きました。ブライアンの講演は、しばしば ACES と略される 4 つの主な属性を中心として、交通機関の将来を垣間見せてくれました。ACES は以下の言葉の頭文字です。 Autonomous (自動) – 車とトラックは、スキャンを行って周囲の状況を理解し、人為的操作なく移動するための機能を備えつつあります。 Connected (接続) – あらゆるタイプの車両に、他の車、およびクラウドベースのリソースへの双方向接続 (常時または断続的) を活用する機能があります。車両は道路とパフォーマンスのデータをアップロードし、群れとなって走る (run in packs) ために互いに通信して、交通と気象データを活用することができます。 Electric (電気) – バッテリーとモーターテクノロジーの継続的な開発は、電気自動車をますます便利でコスト効率がよく、環境にやさしいものにしていきます。 Shared (共有) – ライドシェアサービスは、車の使用を所有型からアズ・ア・サービス型に変えて行きます (聞き覚えがあるのではないでしょうか)。 これらの新たな属性は、個々に、および組み合わせとして、今後10年の間にわたしたちが目にし、使用する車とトラックがこれまでとは著しく異なるであろうことを意味します。 AWS と歩む道 AWS のお客様は、この未来を実現させるために AWS IoT、エッジコンピューティング、Amazon Machine Learning、および Alexa 製品をすでにお使いです。自動車メーカー、それらの一次サプライヤー、そして AutoTech 新興企業はすべて、ACES イニシアチブのために AWS を使っています。AWS Greengrass は、ここで重要な役割を担っており、デザインウィンを引き付け、エッジに処理能力と機械学習インターフェイスを追加するためにお客様を支援しています。 AWS のお客様である Aptiv (旧Delphi) 社は、AWS re:Invent […]

Read More

プロセッサの投機的実行に関する調査の公開について

【日本語訳】日本時間 2018年02月14日19:30 関連する CVE: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754 日本時間 2018年02月06日09:30 以下は本件に関するアップデートです。 Amazon Linux 用の更新されたカーネルは、Amazon Linux のリポジトリにて入手できます。2018年1月13日以降にデフォルトの Amazon Linux 設定で起動された EC2 インスタンスには自動的に最新のパッケージが含まれています。 最新のパッケージでは、 CVE-2017-5715 に対処するための安定版オープンソース Linux セキュリティの改善がカーネル内に組み込まれています。また 以前取り込まれた CVE-2017-5754 に対処するカーネルページテーブルアイソレーション(KPTI)にもとづいて作成されています。インスタンス内の CVE-2017-5715 のプロセスープロセス間の問題と CVE-2017-5754 のプロセスーカーネル間の問題を効果的に軽減するには、最新の Amazon Linux カーネルまたは AMI にアップグレードする必要があります。詳細は「プロセッサの投機的実行 – オペレーティングシステムの更新」を参照してください。 para-virtualized(PV)インスタンスについては、以下の「PV インスタンスガイダンス」の情報を参照してください。   Amazon EC2   Amazon EC2 のすべてのインスタンスは、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 […]

Read More